So there are lots of times you need to work inside a docker container. Being able to do so is a simple but important skill. Easily achieved as below:-
#If your not sure, locate the name of the docker container you want to play in
docker ps
#Then, jump into a bash terminal
docker exec -it container-name bash
The ‘-it’ is the switch/option for interactive terminal . Without it, it will start a bash terminal, but you wont see anything and wont be able to ‘interact’ with it!
So, Nextcloud works pretty good as just a simple server instance rather than AIO (Premade collection of containers), but there comes a time when some maintenance is required.
On the default install, there are no background maintenance running through cron. We can add some.
Photo and file previews
Generating all the previews for a large photo collection takes many hours. Its not something that you want to be “on demand”.
There is a nextcloud app that can be installed which allows you to schedule/perform the preview generation. Aptly named Preview Generator, it can be found in the list of installable apps.
Details on use can be found in :-
Quick summary of some useful options
# Get logged into your nextcloud container.
docker exec -itu www-data nextcloud-container-name bash
# Pre-generate the previews of photos and files
# This is used to generate ALL previews on recent install/reinstall
./occ preview:generate-all [-vvv] [--workers=WORKERS] [--path=PATH] [user_id]The ‘vvv’ option switch is for verbose mode on the command line. Clearly not needed for a headless offering
‘workers’ is for number of concurrent operations
“path” allows specific group of files/folders to be operated on. Using “path” overrides the “user_id”. The path starts from the user name. I.e. :-
“[user_id]/files/Documents/….”
Note the process is running as www-data user due to being the owner of all the files.
The above is very time consuming. The preview generator has another option for just running on the files created after its last run. This is used to keep the thumbnails up to date. Its called “pre-generate”
The general advice on the preview command is to run it as a system cron job. I used the code below to achieve this.
#the following command starts the cron editor
crontab -e
#I then added the following line
* */1 * * * docker exec -u www-data nextcloud /var/www/html/occ preview:pre-generateThe is causing the generator to run once an hour. Again under the www-data user.
So, most of my docker compose scripts are fairly specific, Most are using the :latest tags unless there is a specific reason for not doing so. Updating them can be carried out periodically by running the following
#Once SSH'ed into the hosting server
docker compose pull
#Alternatively, if using profiles
docker compose --profile chosen-profile pull
#If it does pull down any new versions, then stop the
#current containers, build, then restart
docker compose --profile chosen-profile down
docker compose --profile chosen-profile build
docker compose --profile chosen-profile up -d
#For issues, leave off the -d switch to see startup messages. Failing that
#investigate the logs of the containers
docker logs name-container
So, its been a struggle but got it sorted now. I can port from one address to another. Within the docker containers under my charge anyway. Some pointers I found useful
So. My starting point.
I created a new wordpress instance within my docker compose setup. Set it up under Caddy so it gets https. My website is technically two containers. One is WordPress:apache. The other is MySQL. These work in cooperation along with Caddy (Reverse proxy).
I have one additional container I am using for maintenance at the moment. I am running an instance of Myphpadmin for visual inspection of databases.
Step 1. Copying all the website data.
#Login to the remote server
ssh name@server
#Check the name of the running #containers
docker ps
#login to the relevant container
docker exec -it wp-server bash
You are now logged into the wordpress server in a bash terminal. By default, it pops you into
/var/www/html/
We need a copy of the html folder and all subfolders. One issue is that this path also included the wordpress and database backups. These can be quite huge. It helps to exclude these backups.
cd ..
#Lets make a copy of the site data. Lets also exclude the
#backups folder and all sub folders.
tar --exclude="*/backups/*" -czvf site.tar.gz html
#Just for reference, how big is it?
du -h site.tar.gz
#Confirm path
pwd
exit
#We are now back in the hosting server
#Copy the file from the docker webserver to the hosting server
docker cp old-wp-server:/var/www/site.tar.gz .
Step 2. Copying the database data.
Next, we need to create a copy of the database itself. The database does contain some references regarding the address of the website. These will need handled separately.
First, lets get this copied.
There are a couple of options here. I had access to a PHPmyadmin instance to do things visually. Probably overkill though.
The default MySQL installation has a useful command line utility which can be used in this situation. Especially as it can be done over a ssh session with the server.
#Assuming we are still logged into a ssh session running on the hosting server
#The following command may take a short while to run,
#depending on the size of the DB
mysqldump -u root -p database_name > /backup.sql
#Again, as this is moving to another container, it can be pulled back to the hosting server
docker cp old-SQL-container:/backup.sql .Step 3. Search/Replace website references.
At this stage, the database dump file still refers to the old website and if uploaded will cause problems. We need to replace all occurrences to the new (or target) website address. This can be achieved using the sed command
#Replacing the references to the old website
#with the address of the target website
sed -i 's/oldwebsite/newwebsite/g' backup.sqlStep 4. Unpacking the website data.
We are now ready to get the website data from the old site, to the new one, Again, this is a container based movement.
#Lets also get the wordpress copy into the container
docker cp ./site.tar.gz new-wp-server:.
#lets unpack the website data first
docker exec -it new-wp-server bash
#unpack the data into the www folder
mv ./site.tar.gz /var/www
cd /var/www
tar -xzvf site.tar.gz .
exit
#back in the remove server
Step 5. Preparing the new database.
To deal with the database, i found it easier to dump the original and recreate a blank one ready for import
#first lets move the database file
docker cp backup.sql new-SQL-container:.
#Now lets process it
docker exec -it new-SQL-container bash
mysql -u root -p
#enter password
DROP wordpress;
CREATE wordpress;
exit
#Now import the database info
mysql -uroot -p < backup.sql
exit
Step 6. Try it out.
At this point we need to test it out. use the apporpriate command for getting things up and running. In my case, I was using docker compose.
docker compose --profile appropriate-profile up -dIn the event things dont work properly, I can leave out the -d switch to view the messages during the startup of the containers for clues.
Featured images huh? How does that work
Really just trying this blogging bit out
Welcome to WordPress. This is your first post. Edit or delete it, then start writing!