-
Notifications
You must be signed in to change notification settings - Fork 46
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
Package ClusterRunner using Docker container #331
base: master
Are you sure you want to change the base?
Conversation
Verified that @yamaszone has signed the CLA. Thanks for the pull request! |
@josephharrington While adding |
Hi @yamaszone, sorry for the slow response -- I was on vacation and just got back. I'll try to look at this within the next day or two. |
@@ -0,0 +1,11 @@ | |||
version: "2.1" | |||
services: | |||
cluserrunner: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: cluserrunner :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington Thanks! :) Will fix that...
@@ -0,0 +1,13 @@ | |||
FROM python:3.4-slim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity -- what is the naming convention around dockerfiles? I'm assuming you created Dockerfile.src to run clusterrunner from source, and Dockerfile.bin to run it from the binary. Is this more conventional that something like Dockerfile-source/Dockerfile-binary? My main goal here is avoiding confusion around the fact that they look like file extensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington I have seen Dockerfile names with both dot and dash based separation. In some cases I came across Dockerfile name using both! But I agree more with the name you suggested to reduce confusion and to improve readability. Will fix that...
@@ -0,0 +1,11 @@ | |||
version: "2.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this version number come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington Docker Compose has a number of docker-compose.yml
file formats with particular Docker Engine version dependencies. The following explains compatibility requirement and API versioning with upgrade process in details:
- https://docs.docker.com/compose/compose-file/compose-versioning/#compatibility-matrix
- https://docs.docker.com/compose/compose-file/compose-versioning/#versioning
At the time of writing compose file for ClusterRunner in this pull request, Docker version in my CoreOS environment supported compose API version 2.1.
run docker run --rm -v $PWD:/sut -w /sut $CR_SRC build --job-name Simple | ||
assert_contains "$output" "NO_FAILURES" | ||
cd - | ||
# Needs super user privilege as build artefacts are written as root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: artefacts
Same typo at least one other place in this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington I mixed up British spelling with American. I will fix that... :)
@@ -0,0 +1 @@ | |||
#ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to include this directory/file? I saw there was one other empty .gitignore as well -- maybe include a comment in the file about why it's there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington tmp, fixtures, etc. directories are part of the BATS framework. I will add comment in the placeholder gitignore files to clarify that.
|
||
@test "CR-BIN: Help msg displayed by image built from binary." { | ||
run ./run-cr bin -h | ||
assert_contains "$output" "usage: clusterrunner" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bats framework is interesting -- I hadn't heard of it before!
Also the run-cr script is great. I'm interested in your thoughts on doing the tests in Python instead. These seem like simple enough tests to write in Python, and it might be better to keep all tests in the same framework/language just so that they're easier/more likely to be maintained.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington I have been using BATS for a while for health checks/sanity testing for UNIX environments which almost always come with bash
and don't need additional dependency management for this purpose. BATS seems to be a popular in the Docker community (e.g. Docker swarm/machine, Dokku, etc.).
I should be able to convert the sanity tests for CR image using Python but that will mean:
- Docker, Docker Compose are test runtime dependencies although they are not app dependencies.
docker-py
will be another app dependency to do it properly unless using classic Python subprocess.
Both of the above aspects feel a bit heavy considering the purpose, and that's why I intended to keep BATS tests outside the main suite of CR.
I have been rethinking this. Keeping SRP in mind, I'd like to keep the Dockerized distribution responsibility separate from the CR app repository using another repository (say clusterrunner-docker-image). This way:
- Distribution related dependencies will be decoupled from app dependencies and will allow easier maintenance.
- CR Docker image can be independently patched if high priority vulnerabilities found with the base images or dependency related libraries.
I have seen this pattern frequently used for many popular Docker images (e.g. Terraform, Docker library images, etc.). - CR Docker image repo can be built with packages related to distribution via CI. I'll add CI hooks to build automatically via Circle/Travis (to run tests) and Docker Hub/Quay.io (to build image). This will also help us finding known vulnerabilities through security scans.
I will create a POC repo for this soon and would like to know your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington I have created a dedicated repo for ClusterRunner Docker image here. Please let me know your thoughts...
@@ -0,0 +1,22 @@ | |||
The MIT License (MIT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(See my comment below about potentially keeping all tests in Python, but if we did start using bats...)
If possible, I think I'd lean towards not committing the bats library to the repo and instead downloading it (potentially as part of make init
) similar to how we download/install the Python dependencies externally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington It's me being lazy in the early days when I adopted BATS and not being sure if these supporting libraries will be well maintained. :) I forked these repo to address my maintenance concern. I have already fixed this for some of my other repos. I will fix that here too... Thanks for bringing this.
@@ -0,0 +1,57 @@ | |||
## TODO for Dockerization | |||
* Add maintainer(s) | |||
- Maintainer for CR Dockerfile needs to be added after pull request is merged. Ideally the maintainer should be someone from official team with appropriate Docker Hub permission to tag image as `box/clusterrunner:latest`. I can volunteer if needed but that will require collaborator permission for Docker Hub. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on what's involved with this? We have a Docker Hub account named boxinc that I can use. I'm assuming this is something we'd have to do for every new version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington Currently I can push CR images to Docker Hub only using my Hub username i.e. as yamaszone/clusterrunner:src
. The official CR image should be tagged and pushed as boxinc/clusterrunner:latest
, boxinc/clusterrunner:0.5.473
, boxinc/clusterrunner:0.5.474
, etc. which only users under boxinc
and collaborators of a repo have permissions this action. I will include an environment variable CLUSTERRUNNER_VERSION
in the Dockerfile so that there is a Docker image for every version of CR.
* Add maintainer(s) | ||
- Maintainer for CR Dockerfile needs to be added after pull request is merged. Ideally the maintainer should be someone from official team with appropriate Docker Hub permission to tag image as `box/clusterrunner:latest`. I can volunteer if needed but that will require collaborator permission for Docker Hub. | ||
* Lean Docker image (consider tiny base e.g. busybox, alpine, etc.) | ||
- Currently `Dockerfile.src` uses `python:3.4-slim` as the base. I attempted `python:alpine` as the base but it didn't feel like worth the [trouble](https://github.com/docker/docker/issues/27940). My docker version is `1.12.6` but the problem might have been fixed in `1.13.0+`. I will revisit this in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does python:3.4-slim
include more than what is needed? (I assume it does from your comment, but I'm curious as to what.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington The official python:3.4-slim
Dockerfile includes a bunch of dependencies but I am not sure if all of them are needed for CR. I am yet to do a research though...
@@ -0,0 +1,7 @@ | |||
version: "2.1" | |||
services: | |||
cluserrunner: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephharrington Thanks. Will fix that...
@josephharrington Just wanted to let you know that this is in my radar. Thanks for the feedback! 👍 I plan to address them later this month. I will ping you if I need your help on anything. |
Any updates to this? Really would like to see it in docker sometime soon. |
|
@josephharrington 👀
This addresses 1st and 2nd steps for my initial pull request. Please see the TODO notes and let me know your thoughts. This pull request adds 6 new items (one directory and five Docker related files) to the project root and I hope that's tolerable for now! :)