Release/0.6.4 #124
Release/0.6.4 #124
Conversation
mblomdahl
commented
Dec 11, 2017
mblomdahl
commented
- Provisioning and stability updates (Server auto-update of docker-engine kills login.libris.kb.se services #121, Update docker-ce version in ansible playbook #122)
| @@ -11,6 +11,7 @@ | |||
| - tree | |||
| - gcc | |||
| - python-devel | |||
| - yum-versionlock | |||
There was a problem hiding this comment.
According to [0], the package name is yum-plugin-versionlock. I'm guessing they keep yum-versionlock as an alias for backwards compatibility?
There was a problem hiding this comment.
Good catch! Fixing it.
ansible/roles/docker/tasks/main.yml
Outdated
| - name: install docker-ce-17.09.0.ce | ||
| yum: name=docker-ce-17.09.0.ce state=present | ||
| - name: install docker-ce-17.09.1.ce | ||
| yum: name=docker-ce-17.09.1.ce state=present allow_downgrade=yes |
There was a problem hiding this comment.
Would this work if we already have a version lock in place for the package?
There was a problem hiding this comment.
@mxtthias Well... No, that's true. It's not elegant, but I've worked around it by removing the lock before install (and possible downgrade), and adding it back afterwords, in commit 4511943.
I don't know how this will work on next update really. Docker has this annoying practice of obsoleting things aggressively and really forcing you into their preferred RPM package. See e.g. moby/moby#33930 and docker/for-linux#20 (comment)
We should be able to find out if it really-really works by manually installing docker-ce-18.01.0.ce when it's released, then run the playbook again to verify it does indeed successfully downgrade to 17.09.1.
OR, we dodge this mess by reverting the extra complexity added with 4511943, and simply
- install any stable docker-ce version that the Docker repo prefers
- forbid it to auto-upgrade
That's probably more in line with what Docker folks want, so it's easier. Meaning this:
- name: install docker-ce
yum: name=docker-ce state=present
register: yum_install_docker
tags: docker
- name: lock docker-ce version
shell: yum versionlock docker-ce
when: yum_install_docker.changed
tags: docker
Instead of this!
- name: remove docker-ce version lock
shell: yum versionlock delete docker-ce
register: versionlock_delete_docker
changed_when: '"versionlock delete: no matches" in versionlock_delete_docker.stdout'
failed_when: no
tags: docker
- name: install docker-ce-17.09.1.ce
yum: name=docker-ce-17.09.1.ce state=present allow_downgrade=yes
tags: docker
- name: add docker-ce version lock
shell: yum versionlock docker-ce
changed_when: no
tags: docker
@mxtthias What do you think?
There was a problem hiding this comment.
Not specifying a version makes me a bit uneasy. Even if we make sure we only run that task once, when we set up the machine, we'll get unpredictable results if/when we need to do it next time.
Specifying a version will require us to make sure that the version is actually available when we need to install it, which I guess means that we'll have to make sure we stay up to date with the current docker-ce version..
Neither way is awesome, but I lean towards keeping the version specified. What are your thoughts?
There was a problem hiding this comment.
Neither way is awesome, but I lean towards keeping the version specified. What are your thoughts?
I agree! Then the current revision should be what we're seeking. Ready to approve?
| @@ -0,0 +1,3 @@ | |||
| { | |||
| "iptables": false | |||
There was a problem hiding this comment.
Do we need the "experimental": true here?
There was a problem hiding this comment.
No, it was just copied in from my jenkins-up repo; https://github.com/mblomdahl/jenkins-up/blob/master/roles/docker/tasks/configuration.yml
This used to be required in order to build the multi-image containers. It has no place in production environments!
