docker-machine create -d virtualbox default
#create the docker machinedocker-machine ls
#lists the docker machine (not the IP address listed in the URL)docker-machine env default
#lists the env varseval $(docker-machine env default)
#copy these contents into ~/.bash_profilesource ~/.bash_profile
#adds the env vars so you don't need to restart your terminal (may need to add to ~/.bashrc)env | grep DOCKER
#confirm the env vars are setdocker build --build-arg PORT=8001 -t flask .
#if you want to change the exposed portdocker run -e PORT=8001 -e WORKERS=5 -p 8001:8001 --name flask1 -d flask
#if you want to change the workers and bind portdocker exec -it flask1 /bin/sh
#connect to running container- Navigate to app at http://192.168.99.100:8001/
In this test project we have a simple flask app that we would like you to wrap in a container, and test in that same container automating tests and builds to docker hub to your repo in TravisCI.
To host the flask app we ask that you use Gunicorn inside the container.
- Fork the this repository.
- Create a dockerfile for the repository
- Setup tests on Travis CI which run in that
- Travis CI should produce a image and push that to Docker Hub(just a free public repo).
- Submit link to your github repository, include the docker hub link in your repository.
- Create a working docker image that runs the flask app using Gunicorn
- Docker image should take in environment variables to configure port and number of workers.
- Setup a Travis CI environment
- Tests should run inside the docker container in the CI environment.
- Travis CI should continously deliver a new image on commits to
master
. - Create a new README.md which contains build status and link to docker hub
- Use a small base image(like alpine)
- Produce a smaller image with multistage builds -- WIP
- Prerequisites - Docker client and server/machine versions need to be 17.06+
docker version
#determine client and machine versionsdocker-machine upgrade default
#upgrade the docker machine- Check for updates via the Docker for Mac menu item
- I've grasped how to accomplish this using
FROM as base
andFROM base
to make the final container smaller, but am still working through how to chop them up.
- Prerequisites - Docker client and server/machine versions need to be 17.06+
- Provide the yaml for creating a Kubernetes Deployment
brew install kubectl
kubectl version
#to verify versionkubectl cluster-info
#verify cluster is runningbrew install bash-completion
#enable bash completion (follow caveat steps)curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.22.3/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
#install Minikubeminikube --vm-driver=virtualbox start
#fire up single-node Kubernetes cluster with Virtualbox drivers. You can verify by viewing the VM in Virtualbox appeval $(minikube docker-env)
#work with the docker daemondocker ps
#view Minikube-related containersminikube dashboard
#access your dashboardkubectl create -f ./flask_deployment.yaml
#fire up Flask deployment and servicekubectl get deployments
#verify deployment creationkubectl describe services flask-service
#verify service creationkubectl get pods
#list pods running in deploymentkubectl exec <pod_name> -- printenv
#get more details on poddocker ps
#show both Flask containers runningkubectl proxy
#create a connection between our host (the online terminal) and the Kubernetes cluster- Clean up with
kubectl delete services flask-service
andkubectl delete deployment flask-deployment
- Provide a proof of concept for continous deployment to kubernetes
- As I stated on our phone call, Teachstone uses Cloud 66. C66 has a healthy Kubernetes integration.
- I fired up a stack with our project and you can view it here
- The pipeline: commit to master > trigger TravisCI build > successful build triggers c66 deployment w/ new code
- Create python tooling for developers to live reload the application -- can reload gunicorn with
docker exec -i -t flask1 /bin/sh -c '/bin/sh /deploy/app/restart_gunicorn.sh'
- I understand that I didn't create python tooling for this so I tried to think outside of the box. My first approach was to start gunicorn with
--reload
, which will restart the workers when code changes, and start the container withdocker run -p 8000:8000 -v $DEV_ROOT/simple-python-http:/deploy/app --name flask1 -d flask
, which will mount the local filesystem to the app's directory. That way a dev could make changes locally and the app within the container would restart the workers. However, there are known issues with the host file changes not actually making it into the container when using Virtualbox and Docker for Mac. So, I went with an inelegant solution of restarting gunicorn from the command line.
- I understand that I didn't create python tooling for this so I tried to think outside of the box. My first approach was to start gunicorn with