Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENHANCEMENT] Convert containers to releases #574

Open
jhfoo opened this issue Feb 28, 2023 · 4 comments
Open

[ENHANCEMENT] Convert containers to releases #574

jhfoo opened this issue Feb 28, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@jhfoo
Copy link

jhfoo commented Feb 28, 2023

Is your feature request related to a problem? Please describe.
I'm thinking about using Bastille to support horizontal scaling; spinning up new containers of the same app to service increased traffic possibly load balanced via Consul.

Describe the solution you'd like
Once a container is configured allow it to be converted into a release so future instances can be spun up as thin jails quickly.

Describe alternatives you've considered
Thought about running templates to bare releases but stil too slow installing packages and all. Scaling is too slow.

Additional context

  1. Tried to do a soft link from a stopped jail to the releases/ folder. Bastille doesn't recognize the linked folder.
@jhfoo jhfoo added the enhancement New feature or request label Feb 28, 2023
@gamecreature
Copy link

gamecreature commented Oct 12, 2023

I also have a similar requirement, which I could use for rolling deployments of apps.
It would be nice to somehow have a kind of base-jail for other jails.

To base this feature on releases is perhaps a bit hard:

  • The base-jail jail is also based on a given FreeBSD Release. (base-jails based on releases?)
  • At the moment a thin jails uses nullfs to link the base directories. /usr/local space isn't linked.
    To allow user apps in child jails, the /usr/local should be a nullfs link??
    (With all kinds of issues I guess)
  • I think a release based solution is pretty hard to implement

Alternative idea for this is using clones (assuming spawned childs jails/containers are disposable)

  • Use zfs clones to make an (temporary) instance of a base-jail. (The base-jail is kind of of a docker-image)
    Thanks to zfs clone, the jails is identical when created, and hardly consumes any space
  • The data that should survive between creations, should be put in the base-jail (or another location outside the jail) that can be linked with nullfs.
  • When updating the base-jail, you should create new temporary jail to base on this. (because clones don't get updated)

I don't know if @cedwards has any ideas (or plans) for this subject?

(Btw thank you very much for BastilleBSD, I really like it, and also the effort that has been put in this project!!)

@adriel-tech
Copy link
Contributor

Cant the Bastille clone command be used to do something like this?

@gamecreature
Copy link

gamecreature commented Oct 13, 2023

Cant the Bastille clone command be used to do something like this?

Yeah I was thinking about that to. A 'zfs-clone' clone as an alternative option to the current copy (send/recv) clone.

(With clear warning it's a zfs clone. This is not usually what you want when copying a jail by default)

@tschettervictor
Copy link
Collaborator

Bastille now includes a --no-validate flag on creation. This means that you can base your jail on any RELEASE of directory as long as it is inside the $releases directory.

Have you tried this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants