Examples of production deployment about compose

[bfirsh]

We're certainly thinking about how this might work. Would you want to use Fig to deploy to production? What things do you think are missing to make this work?

[beorn]

I assume you don't want to do multi-host orchestration yet, just orchestrating a fig setup on one host.

How would deploying to production be different than development?

Would you still be using Fig on production - if so:

How would you have the OS (initd / systemd / launchd / startupd ...) start up fig services, and keep them always running?

How would you update a running service? (Hopefully very seamlessly.)

How would logging work?

For those that don't want to using Fig for production (in the case they need multi-host orchestration), could Fig integrate with other deployment/orchestration systems - such as being a plugin that reads fig.yml, or dumping out config compatible with other systems?

On Feb 15, 2014, at 15:38 , Ben Firshman [email protected] wrote:

We're certainly thinking about how this might work. Would you want to use Fig to deploy to production? What things do you think are missing to make this work?

—
Reply to this email directly or view it on GitHub.

I've been reading through the Fig code and it probably wouldn't be too terrible of a task to build a tool that can export fig files as json to send through your docker client of choice.
I'm just not 100% sure where the best place to hook into fig to do that. For now, I'm using the branch with -f alt-fig-file.yml on the server so developers can map port 80 to 8000, and on the server it get's bound to a randomized port.
My ideal workflow:
On the developer workstation:
Orchestrate your containers in a fig file
Build the images
Push to a private docker registry

On the server:
Fig file is exported to json
Containers are built, run, and linked via json -> docker client

One question I have not tried answering yet is if volumes follow symlinks.
For example:
Let's say I have /var/www/project as a symlink to ~/releases/release_number
If I tell docker to mount /var/www/project to a container, and later update the symlink to point to a different release_number, will this work?

It seems this may end up being easier than expected. Ubuntu is ditching upstart in favor of systemd.
Production orchestration with Fig may become as simple as using fig2coreos, which reads a fig file and outputs a systemd config file.

Thoughts?

[aanand]

fig2coreos looks great, but having Fig work against a remote Docker daemon using only the remote API would still be a huge win.

I've made some notes after playing with it for a bit, which I'll dump here in the interests of stimulating discussion:

How to use Fig with a remote Docker daemon

To get set up:

• Write an alternate fig file with some important things changed (see below)
• Tell fig to use that file (-f or FIG_FILE - implemented in #113)
• Point fig at the remote daemon with DOCKER_HOST

In your alternate fig file:

• Don't mount volumes that are supposed to come from your machine (e.g. your web app's code).
• Don't expose db container ports to the world.
• Map port 80 to your web container (or put nginx in front).

To start:

$ fig build
$ fig up -d

To deploy changes to specific services:

$ fig build [SERVICE...]
$ fig up -d [SERVICE...]

Issues:

• If the db image doesn't expose ports, there's no way to set it without opening it up to the world. Fig needs to support the expose config option, so that the ports are only open to linked containers.
• fig up results in downtime, as the existing container is shut down before the new one is started/active.
• Dependent services aren't currently automatically restarted, and the order of events is not optimal (see #116).

For context, I'm planning to use Docker containers for isolating Django instances. Each project has three containers; postgresql, redis, and a web server with nginx and uwisgi running under supervisord.

I agree 100% that Fig talking to a remote docker would be a huge win. So far the main thing giving me the willies about that is the lack of authentication in docker. There are some interesting schemes involving proxying through a web server like nginx and using SSL but it would be great if Docker had a built in way of handing this.

Another winning feature would be to export a fig file as either a systemd, supervisor, or upstart script.

So for now, it seems some judicious use of fabric, private registries, and a process manager is the way to go for us.

[aanand]

So far the main thing giving me the willies about that is the lack of authentication in docker. There are some interesting schemes involving proxying through a web server like nginx and using SSL but it would be great if Docker had a built in way of handing this.

Agreed. This is an opportune moment to mention that Orchard (https://orchardup.com/) does HTTPS proxying for you, and that Docker is working on native support (moby/moby#3068).

[karloscodes]

Any progress on this?

[jkingyens]

One way to move forward on this might simply be to add a "fig publish" command that essentially publishes the entire stack by building (if neccessary) and pushing tagged images to the docker repo. While everyones production environment varies widely, we all need to transport/ship images from development to production. This might be a good first step.

[Swatto]

@jkingyens +1

[jkingyens]

I have a pull request for "fig push" (/pull/467). Its good enough for my uses right now but still might need some polish. It pushes all images that are specified as "build" in fig.yml. You pass the repo name with the -r option.

[wernight]

Adding to this, fig is missing Docker -p / --publish commands which are not just to have near zero downtime deployment, but a necessity to have staging environment. Current without that, one cannot simply link a Fig/Docker port to for Prod and another for Staging, or even just run system tests in a completely private port environment, and only expose the port when test pass.

[dnephin]

There are a bunch of related tickets about deployment and production use. I've linked them all up to #1786. I'm going to close this issue so we can concentrate the discussion in that ticket.