2

For our web servers running on Docker containers (Apache, mysql, wordpress, etc) we have a production and a staging virtual machines.

DEVs and content team work on staging and then I tar ball the files from the wordpress container and dump the mysql DB and scp them to production server. Once in production I untar the files to the wordpress container and "restore" the DB. (in fact we use a server in the middle, but I'm skipping that here to keep it short)

I was thinking on an internal docker registry, but that's only for images... so I will need to start/restart the images to container.

Or some kind of internal "GIT"? where I can push/pull versions?

what will be a better way to update production server?

2
  • Your question is quite vague. Could you present concrete alternatives/approaches?
    – Moritz
    Commented Feb 16, 2018 at 11:47
  • I though I did when I described what I'm currently doing (tar the WP files and dump the DB from staging server and copy them to production server abd untar the files and "restore" the DB). I'm looking for a better way to do that, I mean to update the production server with the changes made by developers and content team on staging server.
    – joovunir
    Commented Feb 16, 2018 at 12:08

4 Answers 4

2

My thoughts based on your described scenario are:

  1. Your tarball strategy, as described, might sound safe but is prone to risk in my opinion. A better approach is to version-control the WP files you will modify, while keeping the core intact and within the Docker container. Here's a reference I have used in the past that talks about version-control strategies for WP. You would of course need to spend some time and understand which folders/files to version-control for your specific site.
  2. The version-controlled files would be checked out on the host machine (which runs Docker) and be volume-mounted within your Docker container.
  3. Everytime your changes are validated in Stage they get pushed to Git. Getting these changes into Prod would essentially be a git pull.
  4. If you wish you might also use a tool like composer as part of your deployment workflow. A dependency manager should be part of any deployment worklow.

I would also recommend tying all this together with a tool like Ansible, i.e. use Ansible to

  • update local git repo
  • run the composer bits
  • ensure docker container is running

Disclaimer: Although I've worked on DevOps automation for Wordpress sites, I am by no means an expert on Wordpress, so suggestions and clarifications welcome.

Hope this helps.

1

Or some kind of internal "GIT"? where I can push/pull versions?

What might be of interest to you, without using immutable Docker packages, is Git LFS (Large File Storage). It is an effective approach to using Git for large binaries (your TARs). This has the following benefits:

  1. Use the familiar Git interface
  2. Versioning that allows easy rollbacks
  3. Guards against data corruption

Installing the client is very straight forward although the server requires a few more steps. There are quite a few hosted options available, but self-hosted should be the most cost-effective variant.

1

I’ve been using a private project on Gitlab to push/pull. I’m using Docker Compose to launch the containers in development and production.

Although I am needing to customize the WordPress image now, so I’m using the built in private container registry at gitlab too and thinking of baking all of the updates into the image as well.

0

Once in production I untar the files to the wordpress container and "restore" the DB. One of the advantages of docker that these are immutable packages. If one untars packages in production then this is a contradiction. In my opinion one should pull docker images as is that are immutable. Imagine that a newer version of the docker image, e.g. 1.0.1 is broken then one should be able to revert to the last stable image, e.g. 1.0.0. If one would follow your suggested approach then this is not possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.