<p>My thoughts based on your described scenario are:</p>

<ol>
<li>Your tarball strategy, as described, might <em>sound</em> 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 <a href="https://timnash.co.uk/wordpress-version-control-tips/" rel="nofollow noreferrer">version-control strategies for WP</a>. You would of course need to spend some time and understand which folders/files to version-control for your specific site.</li>
<li>The version-controlled files would be checked out on the <em>host machine</em> (which runs Docker) and be volume-mounted within your Docker container.</li>
<li>Everytime your changes are validated in <code>Stage</code> they get pushed to Git. Getting these changes into <code>Prod</code> would essentially be a <code>git pull</code>.</li>
<li>If you wish you might also use a tool like <a href="https://medium.com/@halles/wordpress-composer-git-1ccf29a9827a" rel="nofollow noreferrer">composer</a> as part of your deployment workflow. A dependency manager should be part of any deployment worklow.</li>
</ol>

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

<ul>
<li>update local git repo</li>
<li>run the composer bits</li>
<li>ensure docker container is running</li>
</ul>

<p>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.</p>

<p>Hope this helps.</p>

CC BY-SA 3.0
2018-02-16T12:41:07.413Z
2018-02-16T12:41:07.413Z
Vish
<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2018-02-19T00:10:07.350Z
2018-02-19T00:10:07.350Z
Jeremy Plack
<blockquote>
  <p>Or some kind of internal "GIT"? where I can push/pull versions?</p>
</blockquote>

<p>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:</p>

<ol>
<li>Use the familiar Git interface</li>
<li>Versioning that allows easy rollbacks</li>
<li>Guards against data corruption</li>
</ol>

<p>Installing the client is <a href="https://git-lfs.github.com/" rel="nofollow noreferrer">very straight forward</a> although the server requires a <a href="https://github.com/git-lfs/lfs-test-server" rel="nofollow noreferrer">few more steps</a>. There are quite a few hosted options available, but self-hosted should be the most cost-effective variant.</p>

CC BY-SA 3.0
2018-02-17T10:03:54.443Z
2018-02-17T10:03:54.443Z
Moritz
<p><code>Once in production I untar the files to the wordpress container and "restore" the DB</code>. 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.</p>

CC BY-SA 3.0
2018-02-16T21:00:03.490Z
2018-02-16T21:00:03.490Z
030
<p>For our web servers running on Docker containers (Apache, mysql, wordpress, etc) we have a production and a staging virtual machines.</p>

<p>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)</p>

<p>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. </p>

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

<p>what will be a better way to update production server?</p>

CC BY-SA 3.0
2018-02-16T11:47:21.473Z
Your question is quite vague. Could you present concrete alternatives/approaches?
Moritz
CC BY-SA 3.0
2018-02-16T12:08:10.643Z
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
<docker><continuous-delivery>
Update production server (apache, wordpress, mysql) on docker containers, from staging server
joovunir
# Update production server (apache, wordpress, mysql) on docker containers, from staging server

(Asked by: username_0 on 2018-02-16)

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?

**Tags:** docker, continuous-delivery

> **Comments:**
> **username_1**: Your question is quite vague. Could you present concrete alternatives/approaches?  
> **username_0**: 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.  

---

## 4 answers

### Answer by username_2 on 2018-02-16. Score: 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](https://timnash.co.uk/wordpress-version-control-tips/). 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](https://medium.com/@halles/wordpress-composer-git-1ccf29a9827a) 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.


---

### Answer by username_3 on 2018-02-19. Score: 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.


---

### Answer by username_1 on 2018-02-17. Score: 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](https://git-lfs.github.com/) although the server requires a [few more steps](https://github.com/git-lfs/lfs-test-server). There are quite a few hosted options available, but self-hosted should be the most cost-effective variant.


---

### Answer by username_4 on 2018-02-16. Score: 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.


---

