Support tagged releases in Travis, Ansible #656
Conversation
| - name: Build application Docker image | ||
| command: > | ||
| docker build | ||
| -f {{ root_app_dir }}/Dockerfile.development |
There was a problem hiding this comment.
Is Dockerfile.development no longer used? If so, we should remove it.
There was a problem hiding this comment.
Also, I see a reference to driver-app:latest a few lines down (line 25), that may need to be modified, but I'm not certain.
There was a problem hiding this comment.
Yeah, I think it needs to reference docker_image_tag.
| on: | ||
| repo: WorldBank-Transport/DRIVER | ||
| branch: master | ||
| tags: true |
There was a problem hiding this comment.
This may lead to two deployments that race, at least if we use git-flow. I think that the completion of a release branch will trigger a build for the merge into master, but also a build for the tagged commit.
There was a problem hiding this comment.
My understanding from the docs is that branch and tags are AND-ed together such that a build is only kicked off if it satisfies both conditions:
When all conditions specified in the on: section are met, your build will deploy.
https://docs.travis-ci.com/user/deployment#Conditional-Releases-with-on%3A
But I have no experience with this aspect of travis so it's definitely possible that that's not quite how it works.
There was a problem hiding this comment.
Hm. This may be true then. I was basing my understanding off of visually seeing builds get triggered for master and tagged commits whenever a release gets finalized (merges into master, develop, and tagged commit). It is possible that at the end of a build it ANDs these conditions together to make a decision.
| docker push "quay.io/azavea/driver-${image}:${TRAVIS_COMMIT:0:7}" | ||
| docker tag "quay.io/azavea/driver-${image}:${TRAVIS_COMMIT:0:7}" "quay.io/azavea/driver-${image}:latest" | ||
| docker push "quay.io/azavea/driver-${image}:latest" | ||
| docker push "quay.io/azavea/driver-${image}:${TRAVIS_TAG}" |
There was a problem hiding this comment.
I think that if we remove on: master above, this will work. Otherwise, I think the TRAVIS_TAG environment variable will be unset when a build is triggered due to changes to master.
There was a problem hiding this comment.
See above; my understanding from the docs is that tags: true will prevent this from running if TRAVIS_TAG is unset.
There was a problem hiding this comment.
Yeah, this seems to back that up too:
tags: true: deployment is triggered if and only if $TRAVIS_TAG is set. Depending on your workflow, you may set $TRAVIS_TAG explicitly, even if this is a non-tag build when it was initiated. This causes the branch condition to be ignored.
doc/system-administration.md
Outdated
| @@ -28,9 +28,11 @@ Each of these servers also includes: | |||
|
|
|||
| ## Deploying updates | |||
|
|
|||
| Deploying updates to production is done using [Ansible](https://www.ansible.com/) (version must be at minimum 1.8). An `ansible-playbook` command is run, which uses the local configuration of the application files in the `deployment` directory to deploy updates to the remote servers. It is not necessary to have the application running locally, but it is necessary to have the latest source code, so make sure to pull down the latest version via `git pull`. In addition to the latest source code, there are four files not checked in to the repository that are needed in order to successfully deploy. These files are as follows | |||
| Deploying updates to production is done using [Ansible](https://www.ansible.com/) (version must be at minimum 1.8). An `ansible-playbook` command is run, which uses the local configuration of the application files in the `deployment` directory to deploy updates to the remote servers. It is not necessary to have the application running locally, but it is necessary to have the source code for the version you want to deploy, so make sure to pull down the latest version via `git pull` and then `git checkout tags/<version>. In addition to the latest source code, there are four files not checked in to the repository that are needed in order to successfully deploy. These files are as follows | |||
There was a problem hiding this comment.
I think that there is a missing backtick toward the bottom of this paragraph:
...so make sure to pull down the latest version via
git pulland thengit checkout tags/<version>. In a...
| - name: Build application Docker image | ||
| command: > | ||
| docker build | ||
| -f {{ root_app_dir }}/Dockerfile.development |
There was a problem hiding this comment.
Yeah, I think it needs to reference docker_image_tag.
| @@ -9,6 +12,8 @@ production: "{{ 'production' in group_names }}" | |||
| docker_version: "1.10.*" | |||
| docker_py_version: "1.2.3" | |||
| docker_options: "--storage-driver=aufs" | |||
| # meta-variable used to translate app_version into docker container tag | |||
| docker_image_tag: "{% if app_version == 'development' %}latest{% else %}{{app_version}}{% endif %}" | |||
There was a problem hiding this comment.
Is it expected that app_version will always be development when you're developing locally?
There was a problem hiding this comment.
No; app_version is ignored completely if developing locally. I'll make that clearer in the comment up top.
This configures Travis to deploy Docker containers with tags matching the built tag on the master branch. It also adds an Ansible variable called `app_version` that can be used to specify which Docker container gets deployed when running production deployments. In development, tags are not used, only `latest` is used.
ddohler
force-pushed
the
feature/versioned-containers
branch
from
ba6bdf2 to
327cefa
Compare
|
Thanks for the comments; they made me realize that I hadn't fully thought through how this would interact with local development (e.g. |
|
Cool, this looks good, I'll merge it. |
Overview
This configures Travis to deploy Docker images with tags matching
the built tag on the master branch. It also adds an Ansible variable
called
app_versionthat can be used to specify which Docker imagegets pulled onto host machines.
The general scheme here is as follows: Previously, merges to
developwould deploy Docker images with thelatesttag, and all deployments of DRIVER currently are hard-coded to pull and run thelatestimage. Merges tomasterhad essentially no effect. Now, merges todevelopcontinue to behave the same way, but adding new tags tomasteralso deploys images which are tagged to match the git tag. In this way, we can have deployments that are pinned to specific versions which will be unaffected by subsequent merges tomaster.Tagged images can be pulled and run by our deployment scripts by specifying the
app_versionparameter ingroup_vars. Ifapp_versionisdevelopment, then thelatestdocker tag will be pulled. Otherwise, the value ofapp_versionwill be used.app_versionis ignored in Vagrant because there we build Docker images based on the application source, rather than pulling from Quay.Because the behavior of merging to
developis unchanged, this should be backwards-compatible with existing deployments (although I don't think we were relying on this specific behavior anyway).Testing instructions
masterNotes
masterresult in new docker images. This is by design in order to be conservative about how much fragmentation we encourage in the ecosystem until we have more people using this in production. If it becomes necessary in the future, it's easy to remove this restriction; it should be as simple as changingbranch: masterin.travis.ymltoall_branches: true. This would then deploy images for all tags, regardless of the branch, which would in theory allow us to run several parallel branches with very different features (e.g.master-br,master-ph,master-sa, etc.).1.0.0placeholder inall.exampleshould be changed to the actual first version number we want to use before we merge tomaster.docker-composebased setup for easier local development.