[Feature request] deployment/releases functionality

[mahnunchik]

Hi,

Do you plan to add deployment/releases functionality to the docker-compose?

I mean:

• Deploying a new version of the service or services specified in the configuration
• Rolling back to a previous release

If not, could you please recommend a tool for that kind of tasks for small projects without clustering, private registry, and orchestration?

[mahnunchik]

hey somebody 🐼

[xvik]

+1

[funkyfuture]

it may help if you posted some example scenario and usages. posting +1 won't.

[mahnunchik]

Hi @funkyfuture

For example we have a simple app. We run it with the following docker-compose.yml config:

web:
  build: ./
  ports:
    - "8080:80"
  links:
    - db:DB
  environment:
    MY_AWESOME_ENV: 123
db:
  image: mariadb:latest

By docker-compose command:

$ docker-compose up

It is great for development!

---

My question is about deployment functionality.

For small projects without private registry usage, it would be enough to have something something like this:

$ docker-compose deploy web

To create the latest image and run it (for example: web_image_201504DDHHMMSS and web_201504DDHHMMSS)

And to have the rollback command:

$ docker-compose rollback web

To start the previous container (or run container from previous image).

[mahnunchik]

Does anyone know of such a tool?

[funkyfuture]

i think you're asking for a feature to keep previous containers of a project when recreating. that'd sound reasonable to expect from compose and should be easy to implement when labels are used to handle containers.

you may open a feature request concerning this. this should be discussed before implementation as there are propably different design approaches.

[aanand]

Deployment in general is something we need to think about more, yes. There are lots of different scenarios with lots of particular requirements, but I'd like to investigate supporting a simple deployment strategy that'll work for a majority of people.

In particular, this might involve:

• Tagging of images before deploying them
• Graceful restarts, updating load balancers
• Not deleting old containers straight away, but perhaps implementing a "cleanup" command
• Rollback

[funkyfuture]

one important apect came across me today: if there is an option to keep a prior container also its volumes should be preserved. for self-contained ones that may be easy and reasonable to support, but it gets tricky with volumes_from and mounted volumes.

[schmel]

Try Zodiac
https://www.ctl.io/developers/blog/post/zodiac-easy-container-deployment-rollback/

[dnephin]

Consolidating all production related issues into #1786