I have a hunch that docker could greatly improve my webdev workflow - but I haven't quite managed to wrap my head around how to approach a project adding docker to the stack.
The basic software stack would look like this:
Software
Docker image(s) providing custom LAMP stack
- Apache with several modules
- MYSQL
- PHP
- Some CMS, e.g. Silverstripe
GIT
Workflow
I could imagine the workflow to look somewhat like the following:
Development
- Write a
Dockerfile
that defines a LAMP-container meeting the requirements stated above- REQ: The machine should start apache/mysql right after booting
- Build the docker image
- Copy the files required to run the CMS into e.g.
~/dev/cmsdir
- Put
~/dev/cmsdir/
under version control
- Put
- Run the docker container, and somehow mount
~/dev/cmsdir
to/var/www/
on the container - Populate the database
- Do work in
/dev/cmsdir/
- Commit & shut down docker container
Deployment
- Set up remote host (e.g. with ansible)
- Push container image to remote host
- Fetch
cmsdir
-project via git - Run the docker container, pull in the database and mount
cmsdir
into/var/www
Now, this looks all quite nice on paper, BUT I am not quite sure whether this would be the right approach at all.
Questions:
While developing locally, how would I get the database to persist between reboots of the container instance? Or would I need to run sql-dump every time before spinning down the container?
Should I have separate container instances for the db and the apache server? Or would it be sufficient to have a single container for above use case?
If using separate containers for database and server, how could I automate spinning them up and down at the same time?
How would I actually mount
/dev/cmsdir/
into the containers/var/www/
-directory? Should I utilize data-volumes for this?Did I miss any pitfalls? Anything that could be simplified?
I understand this post is over a year old at this time, but I have recently asked myself very similar questions and have several great answers to your questions.
You can setup a MySQL docker instance and have data persist on a stateless data container, aka the data container does not need to be actively running
Yes I would recommend having a separate instance for your web server and database. This is the power of Docker.
Check out this repo I have been building. Basically it is as simple as
make build
&make run
and you can have a web server and database container running locally.You use the
-v
argument when running the container for the first time, this will link a specific folder on the container to the host running the container.I think your ideas are great and it is currently possible to achieve all that you are asking.
Here is a turn key solution achieving all of the needs you have listed.
If you need database persistance indepent of your CMS container, you can use one container for MySQL and one container for your CMS. In such case, you can have your MySQL container still running and your can redeploy your CMS as often as you want independently.
For development - the another option is to map mysql data directories from your host/development machine using data volumes. This way you can manage data files for mysql (in docker) using git (on host) and "reload" initial state anytime you want (before starting mysql container).
Yes, I think you should have a separate container for db.
I am using just basic script:
Yes, you can use data-volumes -v switch. I would use this for development. You can use read-only mounting, so no changes will be made to this directory if you want (your app should store data somewhere else anyway).
Anyway, for final deployment, I would build and image using dockerfile with
ADD /home/user/dev/cmsdir /var/www/cmsdir
I don't know :-)
You want to use docker-compose. Follow the tutorial here. Very simple. Seems to tick all your boxes.
https://docs.docker.com/compose/
I've put together an easy to use docker compose setup that should match your development workflow requirements.
https://github.com/ehyland/docker-silverstripe-dev
Main Features
HHVM
+NGINX
orApache2
+PHP5
The README.md should be clear enough to get you started.