3

How to deploy multiple instances (40+) of the same application with gitlab? (it is a simple tomcat web app)

I want to be able to individually upgrade/downgrade them using web interface.

We already have a working gitlab+docker pipeline that deploys one instance of an app. We are not using k8s yet.

Should we create gitlab environment for each instance? Do we have better options besides gitlab environments?

Update: Instances (websites) do differ, they have the same codebase but different configuration. Right now the scaling is not a priority, what we really want is to have an interface to add, deploy, upgrade and downgrade websites. I've tried gitlab environmets on a smaller project and it's really awesome when you have like one or two websites, but when you have 10 or more and you have one environment for each website .gitlab-ci.yml grows exponentially.

Improve this question
2
  • If you want to "be able to individually upgrade/downgrade them using web interface." you probably want to have individual jobs for them. However, this doesn't seem like good practice. Perhaps you should consider Docker Swarm (if you're not ding k8s) and apply rolling updates to the running services?
    – Bruce Becker
    Commented Nov 28, 2018 at 3:57
  • same codebase but different configuration I wonder does the configuration change only in one file? You can have multiple environments and use yaml inheritance stackoverflow.com/questions/44287955/…
    – Kyslik
    Commented Nov 29, 2018 at 9:49

1 Answer 1

Reset to default
3

The documentation shows that you can have 40+ branches with different configurations. You express concern that the configuration becomes large. With a good editor that isn't really a problem. Yet that feels wrong, right?

With git, in general, a repository per independent deployable works better than a single repository holding many independent deployables. So an alternative layout is not 1 repo with 40 branches, but 1+40 repos. That would be 1 repo that builds the latest code and creates releases. Then 40 repos that represent the configuration to deploy a particular release of the code configured for one website. The 40 repos that deploy the code can hold the 40 per-website configurations and a standardised build script that simply downloads the right release of the code to deploy along with the website configuration into the environment.

We use 1+N+M git repos. We have 1 repo that holds the deploy scripts. They are versioned and released. We have N repos that build the different apps into releases. Currently, two php apps and two react apps that work together but are deployed and upgraded independently. Then M repos that represent the environments/sites we deploy into which is currently only staging and live.

We are using k8s (OKD) and the deployment scripts are using helm. That just means that our deployment scripts and environment setup are simpler and rollback/downgrade is fully automated. We don't actually download the app to deploy during our build. Instead, we simply push out the docker registry tag of the version of the code we want to deploy into a given environment.

I started a project to opensource our approach to deploying apps from git which is called OCD. It is still a work in progress but it demonstrates some of the above ideas.

Improve this answer
3
  • How do you pass docker tag from build repository to deploy repository without manually adding it
    – azeko
    Commented Nov 30, 2018 at 18:09
  • @azeko a release event in git fires a release git webhook that triggers a build that makes an image that is given the same tag in the docker registry. then to release that version of the code you tag the repo that holds yaml that names all the versions to deploy to the environment. a second release event in git then runs a build that deploys look at the versions named in the yaml and applies that to the environment. various build tools can be configured to automatically build or deploy or both on git tags.
    – simbo1905
    Commented Nov 30, 2018 at 18:40
  • @azeko to your specific question if you run a docker build due to a git release event you can parse the git tag out of the release event payload, git checkout that version of the code, build it, push it to the docker repo, then tag it in the docker repo with the same tag. with OKD builds that OCD manages its done slightly differently to work around that OKDs s2i buids don't make it easy to just do a docker tag at the end.
    – simbo1905
    Commented Nov 30, 2018 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.