0

I have project running using several docker containers. Now I want to automate deployment using Jenkins (push triggers). I have three scenarios but I like none of them. here are these three different scenarios:

1) I deploy changes on server, then on server I run docker-compose build, to recreate potentially changed images and then run containers.

downside - I don't build these new images on my host, but just on the server, so I can't be sure that build will occur successfully, It may be buggy and cause several errors without first checking.

2) I can first check that project builds successfully but first running docker-compose build on my Jenkins server and deploying after that.

downside - I run docker-compose build two times. on my Jenkins server and on the production server.

3) I can build on my Jenkins server, then push it on docker hub and pull on server. so I build only once.

downside - as I said I have several images. so in this scenario I have to upload maybe 6 images on the docker hub and then pull them on server.

As I said I don't want to use any of these because of their downsides. So maybe there are other better way of doing things like that?

O. Shekriladze
  • 101
  • 1
  • 1
    Hi! This is a really interesting question and there isn't one good answer. We could have a lengthy discussion on this. Many people face the same challenges. Unfortunately, this isn't a good place to have that discussion, see the guidelines here https://serverfault.com/help/dont-ask. Have you found a Slack channel where you can discuss? If you have a specific problem using either Docker or Jenkins maybe you can repost this question. – Mike Marseglia May 13 '19 at 17:10
  • https://www.networktocode.com/community/ would be the place I'd start in Slack-land. It might also be on-topic at https://devops.stackexchange.com/ . – chicks May 13 '19 at 19:37
  • 3 should be the winner so you have an archive of your artifacts. Your downside there seems relatively thin and vague to me. – chicks May 13 '19 at 19:39

1 Answers1

0

It's usually good practice to split out your build and deploy steps to separate jobs. This way you build/test once and can migrate the versioned image across your environments when ready. You can also trigger the build to occur whenever the code changes, creating unique image version#'s when needed.

Your deploy job should contain an option to specify the docker image version to deploy which also helps with rollback. Option #3 IMO is the best one.

If you don't want to bother with dockerhub, you can easily create a local docker registry that you can push to as well to keep your images. See docker_registry

abe
  • 1