The post-instruction me not forget the pain and the flow I used for it.

So I’ve heard recently about the docker and I really liked the idea to have a self-container with basically anything you want to run and test. Why I was thinking about it? Because I always was afraid of what will happen if my provider will kick me off the hosting and will I be able to move my backups to a new server with minimum effort and pain.

A long time ago, I tried to create a local server with a lot of crap settled on my pc. It worked out, but I really did not like the way how I was doing this. The idea to have it in a single self-contained place where I can (theoretically) easily move it to another server with docker running without any struggle seems way more attractive.

Let me combine a list of steps I need to hit to call the operation successful:

1. Run docker container with wordpress + mysql
2. Move the desired website to the docker container
3. Create an image of the container, move it to another server and check if it still works

Starting from the first one:

Run docker container with wordpress + mysql

There are tons of articles on how to deploy wordpress on docker, but many of them misleading and non-repeatable (at least by me), I found that one turned out to work for me, but not immediately.

The docker-compose.yml file I ended up using is there:

version: '3.7'

volumes:
  wp-data-org:
networks:
  wp-back-org:

services:

  db:
    image: mysql:5.7
    volumes:
      - wp-data-org:/var/lib/mysql
    environment:
       MYSQL_ROOT_PASSWORD: rootPassword
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wp-user
       MYSQL_PASSWORD: wp-pass
    ports:
      - 8869:3306
    networks:
      - wp-back-org

  phpmyadmin:
    depends_on:
      - db
    image: phpmyadmin/phpmyadmin
    environment:
      PMA_HOST: db
      MYSQL_USER: wp-user
      MYSQL_PASSWORD: wp-pass
      MYSQL_ROOT_PASSWORD: rootPassword
    ports:
      - 3061:80
    networks:
      - wp-back-org

  wordpress:
    depends_on:
      - db
    image: wordpress:php7.3
    ports:
      - 8868:80
      - 463:443
    environment:
       WORDPRESS_DB_HOST: db
       WORDPRESS_DB_USER: wp-user
       WORDPRESS_DB_PASSWORD: wp-pass
    volumes:
      - ./wordpress-files-org:/var/www/html
    container_name: wordpress-site-org
    networks:
      - wp-back-org

A couple of things I have changed from the source:

port numbers have changed to 3061 for mysql, 8868 and 463 for the wordpress. I did this because I’m planning to deploy both my websites locally, so I need different ports.

The same reason for volumes and the network’s different names.

An important thing – I’ve got a lot of “Error connecting to databases”, I spent tons of time before I figured out that when I changed the db name or user name and pass to match with my website, it was killing this wordpress installation. I dont care much how it is called locally, so I gave up and left it be just “wordpress”, this is fine.

Another thing wordpress:php7.3 – I am not pulling the latest image since my website has an older php, and there is no simple update procedure for php on my webservice. So I rather just try to align versions .

Also, when experimenting and cleaning the docker environment by command docker-compose down, it appears that docker volume has not been cleaned, so there is one extra step required with docker volume rm volume_name for the proper clean-up.

So after the docker-compose.yml file has been created, we need to run the command:

docker-compose up -d

After this you can check the status of the service by running the command docker ps:

To check created networks we can launch – docker network ls:

To check volumes – docker volume ls

Now, if you go to your localhost:8868 you will see the wordpress installation webpage, which I proceed to and from the moment I was ready to:

Step 2: Move the desired website to the docker container

Obviously, it did not go smoothly. Initially, I’ve logged into phpmyadmin on my webservice and exported the database, thinking that I have no issues with it. Then I went to localhost:3061 where my docker phpmyadmin was running and tried to import the database. It constantly gave me different errors about the bad request and other stuff I don’t understand. Finally I tried to export the database not through phpmyadmin but just by some button available on the server, then the local phpmyadmint ate this database without any error. I kind of suspect that a similar result would be if I would have used the pure mysql thru the terminal.

The database has been imported but the website stopped working – just a blank page was there. After a bit of panic and I realized that it can’t work without the same setup and all files available locally. So I copied over all the web folders related to wordpress to my local wordpress folder. Well, not all of them – wp-config.php should be there as it was during docker container deploying. Moreover, in this file after some strings saying stop editing here bla bla bla, we need to add two strings:

define('WP_HOME', 'http://localhost:8868');
define('WP_SITEURL', 'http://localhost:8868');

Then, just in case restart the docker containers: docker-compose restart and check if we have working local website:

Looks right to me. Now, what if I want to move the container to another pc/server, will it work w/o issues or will I struggle again?

Step 3: moving to the different server

So if you wonder what is the answer – of course, I struggled. That is the step where I lost the charm of the beautiful idea behind the docker. It is appeared to be that this is not that easy after all to move the service to another server. You need to copy the container, volume, image, redefine ports, and perform a set of commands, ahh. I am not a sys. admin, don’t want that many details on my head.

Another solution was to copy over the whole /var/lib/docker which I tried as well. Did not work and I suspect this is due to a reason I also have a local folder with wp files, which I have no idea how to relink. Again, I am not a sysadmin.

Long story short – I gave up. Deploying the local website appeared to be much simpler than moving it over another machine. I have database backups each couple of days and the same about files, so I kind of made a decision that it doesn’t worth spending my time on it anymore. A bit of practice is performed – good enough, the deployment manual is there and will be handy for me in an emergency case.