Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement dockerhost.yml playbook for systems running static docker containers for test #1925

Merged
merged 6 commits into from
Feb 19, 2021

Conversation

sxa
Copy link
Member

@sxa sxa commented Feb 12, 2021

Checklist
  • commit message has one of the standard prefixes
  • FAQ.md updated if appropriate
  • other documentation is changed or added (if applicable)
  • playbook changes run through VPC or QPC (if you have access): VPC VPC
  • for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

This adds in a new playbook for creating a "Docker-only" host which holds statically built containers used to run testing (Formalises what was prototyped in issue 1809). It contains:

  • New "DockerStatic" role to create and start one container on each of Ubuntu 16.04/18.04/20.04/20.10, Fedora 33 and CentOS 8
  • New adopt_etc role which contains the items from Common which make changes to the system hostname etc. (Since we don't want all of the Common things in the dockerhost.yml
  • Move of the definitions of the crontab_patching things from Common to the Crontab role so that it doesn't require Common to be executed first (makes the role self-sufficient)

To be addressed (potentially later - these would be good "introductory" things for new people to resolve):

@sxa sxa added this to the February 2021 milestone Feb 12, 2021
@sxa sxa self-assigned this Feb 12, 2021
@sxa sxa changed the title Dockerstatic Implement dockerhost.yml playbook for systems running static docker containers for test Feb 12, 2021
@sxa sxa force-pushed the dockerstatic branch 2 times, most recently from 7aabfa1 to aed49ac Compare February 12, 2021 14:06
@sxa
Copy link
Member Author

sxa commented Feb 12, 2021

Not quite sure yet what it's complaining about - ansible-lint does not object in the same way when run on my local machine.

@sxa
Copy link
Member Author

sxa commented Feb 12, 2021

With updates to the core file settings ought to fix #1817 but it doesn't as it's not taking effect, so I'll do that in a follow-on PR, which will hopefully end up in adopt_etc to help with #1817 if we put more guards on it :-)

@sxa sxa force-pushed the dockerstatic branch 5 times, most recently from 9528afc to a1ebdfe Compare February 12, 2021 18:06
@sxa sxa marked this pull request as ready for review February 12, 2021 18:42
@sxa sxa force-pushed the dockerstatic branch 3 times, most recently from 2aaad9d to c93f2c7 Compare February 15, 2021 16:42
@sxa
Copy link
Member Author

sxa commented Feb 15, 2021

NOTE TO REVIEWERS:

  • Does not contain NTP_TIME role because the requisite packages are not installed since we don't run Common at present
  • Nagios plugins do not work on the hosts I'm using. That can be resolved laster
  • Because of the way I've put the jenkins ssh key in, I can't also have the bastillion ssh key along with it as well from Vendor_Files, so this breaks the ability for bastillion to administer up the jenkins user (Can fix separately)

Signed-off-by: Stewart X Addison <[email protected]>
Copy link
Contributor

@aahlenst aahlenst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comments regarding the Ubuntu Docker file apply to all to Ubuntu/Debian Docker files.

# Clear up space
RUN rm /tmp/jdk8.tar.gz /tmp/ant.zip /tmp/ant-contrib.tgz
# Set up jenkins user
RUN useradd -m -d /home/jenkins jenkins
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should predefine a UID/GID that does ideally not collide with a host UID/GID. One popular recommendation is to use 10000.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these containers are fully isolated and not sharing the file system with the host (unlike the build ones) that shouldn't be a concern for these.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to my understanding, you can still escape from the container and end up with the same UID on the host as in the container as long as Docker user namespacing isn't active and configured. If I read the Dockerfile correctly, sshd is run as root, anyway, so it might make sense to tackle this in a separate PR if we really need sshd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants