Continuous Delivery

[...] the container. In this series of blog posts we will show you how to run a Python webapp in a Docker container, test that container locally and through an online CI tool called Wercker, and then deploy [...]

[...] with the tutorial using Docker instead of virtualenv. In order to get this running inside a Docker container we need a few more things. The example_app.wsgi file contains instructions for interfacing [...]

[...] Part 2 – Continuous Integration and Deployment Introduction This is the second part of a series. If you missed part 1 you [...]

[...] in the near future. In the next blog post you I will show you how we tackled the issue of continuous integration when working with Docker, and after that, we’ll look at continuous deployment. [...]

[...] before committing our code for our CI tool to pick up. It is here that we can run our Python web application container during development to visually check it on the Vagrant Host. Lastly, this is [...]

[...] case is a Docker enabled AWS instance. * In part 1 we will look at setting up the Docker development environment and the workflow we used when developing against layered Docker images. Assumptions and [...]

[...] part 1 you can check it out here. It is required reading. In part 1 we set-up our local development environment. In part 2 we will show you how we used Wercker, a hosted continuous integration tool to [...]

[...] , you will also not be able to docker push your built Docker images to our account on the central Docker repository. Our suggestion then is the following: Create an account on the central Docker [...]

[...] very rarely and we do not build it ourselves at all. Instead it is pulled from the central Docker repository by Docker when required. python_webapp https://github.com/mrmrcoleman/python_webapp This [...]

[...] /mrmrcoleman/ud_visualise This is our application layer which inherits from the python_webapp Docker image and installs our Python code plus some related files. We expect to rebuild this image every [...]

[...] and wire it up. We’re going to do this in a new project that just refers to the Docker image we just built rather than modifying the original project directly. Create a new project [...]

[...] test.sh in part 1. push.sh is the script which takes our successfully built and tested Docker image and pushes it to the central Docker index from where it will later be deployed. [...]

[...] layer which inherits the Ubuntu:Quantal Docker image and installs Apache2 and our Python dependencies which are listed in the requirements.txt file in the GitHub repository. Note that we don’t [...]

[...] It doesn’t provide “true” isolation; only Python level (system libraries and non-python dependencies will still cause issues) I typically don’t want to run virtualenv in production, [...]

[...] ’s performance to the stock market. Because we needed to move quickly we decided to use Docker containers. We were working in a team of two; my colleague Adrian doing the development, and me doing [...]

[...] through this post will give a pretty firm understanding of how to work with Wercker and Docker containers. And finally, as in the last post I’m not going to dig into every line of every file as it [...]

[...] section above, we need to build the python_webapp image first: If we now take a look at the local Docker images we can see that ubuntu:quantal was downloaded and used as the base image to build [...]

[...] Wercker is currently not ideal Creates a new image each time which means that we lose our local Docker images and they have to be rebuilt each time which slows us down We cannot have dependant builds [...]