I am in the middle of no where. Following this tutorial https://cloud.google.com/container-engine/docs/tutorials/persistent-disk
I deployed wordpress to google container engine. Now i have no idea how to access wordpress files on this Persistent Disks either with ftp or sftp. I can access project files with sftp on filezilla but can't find wordpress core files in it. Is there any way i can access these wordpress files?
The persistent disk containing the wordpress files are attached to the wordpress pod. This disk is mounted on /var/www/html folder under the wordpress pod. You can access these files by connecting to the wordpress pod. First get the name of the running pod by executing the following command,
kubectl get pods
Now use the name of the wordpress pod in the following command. This runs a remote shell on the wordpress pod,
kubectl exec -it <POD_NAME> sh
In the shell, run the ls command to see the list of wordpress files,
# ls
This will list the wordpress files. If you want to edit these files, you need to install vim or nano.
# apt-get update
# apt-get install vim
# apt-get install nano
# vi wp-config.php
Note that the vim/nano will be removed if the wordpress pod is restarted. If you really want them inside your pod, you will need to create a custom container.
First take a look here: https://stackoverflow.com/a/46011597/1197205
This plugin uses Google Cloud Storage so it's easy to access via the UI
Another solution (only if you run 1 pod because otherwise you'd need to sync between disks): use an sftp container as a sidecar for the wordpress pod
Related
I can't ssh to the Azure App Service wordpress site and seems it has been disabled within it.
Referred following url to setup the Site.
https://learn.microsoft.com/en-us/azure/app-service/quickstart-wordpress
Any idea on how can i enable this ?
Enable SSH on Azure AppService - Wordpress
Any idea on how can i enable this ?
To enable ssh for WordPress settings you first need to create normal webapp with docker container and then we need to deploy WordPress image in container.
After creating the docker container find the command for deploying WordPress docker image.
Check this document for more information on docker deployment.
for Docker image deployment check the official website
``console
$ docker run --name some-wordpress --network some-network -d wordpress
- *Here are the commands for installing SSH config file*
cat sshd_config
```
Here is the output
let me clarify the situation:
Run wordpress docker container with:
docker run --name wp -d -p 80:80 wordpress
Login to a running container using bash:
docker exec -it wp /bin/bash
Create 2 dummy files:
One in root:
touch /xxx
One in wp-content/themes
touch /var/www/html/wp-content/themes/xxx
Create a new wordpress image:
docker commit wp new_wp
Kill the original container:
docker kill wp
Run new docker image:
docker run --name new_wp -d -p 80:80 new_wp
Inspect dummy files created in step 3:
Dummy file in root exists
Dummy file in wp-content/themes no longer exists!!!
Questions:
Can anyone explain such a bizare behaviour in step 7?
What am I supposed to do to persist wp-content data?
P.S. I am deploying to AWS ECS Fargate instances therefore using volumes is not very practical for me. Ideally - I would love to have everything under one image without files disappearing from wp-content directory.
Thank you very much for your answers.
The docker image for wordpress includes a VOLUME statement:
VOLUME /var/www/html
This forces a volume to be created on any resulting containers even if you do not specify one in your docker run command. Without a specification, you will get an anonymous volume with a long unique id that can be seen in docker volume ls.
The docker commit command (which I strongly recommend against using in any workflow that you want repeatability) only captures changes to the container filesystem (you can see these with docker container diff). The changes to the volume are not part of the container filesystem, and therefore will not be included in this commit.
To persist data, you should be defining and using a volume, e.g.:
docker run --name wp -v wpdata:/var/www/html -d -p 80:80 wordpress
Docket is inherently non-persistent.
If you want to leverage docker for WP I highly recommend offloading image asset management to S3 and Cloudfront.
I can't seem to get Web App for Containers (S1) to deploy a Wordpress image from Azure Container Instance with HTTPS working for the admin section. The wp-config.php configuration file are taken from the samples on github provided by microsoft and the Dockerfile is extended from wordpress:4.9.5-php7.2-apache
# Pull image from official source with version specified
FROM wordpress:4.9.5-php7.2-apache
# Overwrite Wordpress configuration
COPY ./wp-config.php /usr/src/wordpress/
# Add permissions needed for wordpress to run
RUN chown -R www-data:www-data /usr/src/wordpress/
WORKDIR /var/www/html
I can build the image, push it, and deploy it to Web App for Containers, but when I try to log into the admin portal using https I am redirected to the non-https login.
The docker logs on Web App during container invokation looks like below
2018-04-23 07:57:21.751 INFO - Starting container for site
2018-04-23 07:57:21.751 INFO - docker run -d -p 58688:80 --name my-test-website__c20c_2 -e WEBSITE_SITE_NAME=my-test-website-name -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=...3cfaeb147447885bccba4565fb6192f -e HTTP_LOGGING_ENABLED=1 myacrregsitryhere.azurecr.io/wordpressdocker:21483
Things that I have tried:
allow http/s in wp-config like so:
define('WP_HOME', '//'. filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
define('WP_SITEURL', '//'. filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
define('WP_CONTENT_URL', '/wp-content');
define('DOMAIN_CURRENT_SITE', filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
which results in redirect loop that is stopped by the browser.
Azure Web app enforce https
results in redirect loop that is stopped by the browser.
Enforce ssl via wp-config.php
define('FORCE_SSL_ADMIN', true);
How am I supposed to get https working with slots in Azure Web App for Containers?
You can enforce SSL for that web app in the portal, i.e. as per https://learn.microsoft.com/en-gb/azure/app-service/app-service-web-tutorial-custom-ssl#enforce-https
I have multiple AWS EC2 instances which are updated from a Git repository via CodeDeploy. However, since keeping the wp-content/uploads folder in Git is messy and hard to maintain, I'm instead trying to move all uploads to a directory which I have mounted as an EFS filesystem. That way I should be able to share the uploads between multiple EC2 instances.
However, now I'm running into a new problem; there's no way for me to set the WP uploads folder to be outside of the WP root.
WordPress is located at /opt/bitnami/apps/wordpress/htdocs, which is also where our domain points. The EFS system is mounted to /home/bitnami/efs. Since the EFS directory is located outside of the WP root there's no way for me to link to it.
I have gotten this to work using a symlink directing the default wp-content/uploads folder to my desired path; however, this doesn't really solve my issue since I can't rely on the symlink to not be overwritten during CodeDeploy deployments.
So my questions are as follows:
Is it possible to have this setup work without using a symlink, so I can make deployments without worrying about by uploads being affected?
If a symlink is the only/best way to make this work, is there any way to add the symlink to the git repository, or any other way to make absolutely sure it persists during CodeDeploy deployments?
You can directly mount your EFS to /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads to avoid symlinks.
In your appspec.yml add two hooks:
hooks:
BeforeInstall:
- location: /deploy/BeforeInstall.sh
timeout: 3000
runas: root
AfterInstall:
- location: /deploy/AfterInstall.sh
timeout: 3000
runas: root
Then create directory deploy and two files in it BeforeInstall.sh and AfterInstall.sh
BeforeInstall.sh unmount the EFS if its mounted
#!/bin/bash
if mount | grep /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads > /dev/null; then
sudo umount /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads
fi
Then mount EFS again via AfterInstall.sh after deployment
#!/bin/bash
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-fxxxxxx.efs.us-west-2.amazonaws.com:/ /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads
Note: You can also mount entire wp-contents directory, not just uploads folder, so that update in themes and plugins also get reflected in other EC2s automatically.
Also, symlink is a better solution, so you don't have to ever worry about accidentally removing the EFS mount during deployment if umount ever fails. You can just recreate symlink again after deployment using AfterInstall hook and add code in file AfterInstall.sh
#!/bin/bash
ln -s /home/bitnami/efs /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads
It's quite easy to mount a host directory in the docker container.
But I need the other way around.
I use a docker container as a development environment for developing WordPress plugins. This docker container contains everything needed to run WordPress (MySQL, Apache, PHP and WordPress). I mount my plugin src folder from the host in the docker container, so that I can test my plugin during development.
For debugging it would be helpful if my IDE running on the host has read access to the WordPress files in the docker container.
I found two ways to solve the problem but both seem really hacky.
Adding a data volume to the docker container, with the path to the WordPress files
docker run ... -v /usr/share/wordpress/ ...
Docker adds this directory to the path on the host /var/lib/docker/vfs/dir... But you need to look up the actual path with docker inspect and you need root access rights to see the files.
Mounting a host directory to the docker container and copying the WordPress files in the container to that mounted host directory. A symlink doesn't seem to work.
Is there a better way to do that? Without copying files or changing access rights?
Thank you!
Copying the WordPress files to the mounted folder was the solution.
I move the files in the container from the original folder to the mounted folder and use symbolic links to link them back to the original folder.
The important part is, the container can follow symbolic links in the container and but the host can't. So just using symbolic links from the original folder to the mounted folder doesn't work, because the host cannot follow symbolic links in the container!
You can share the files using smb with svendowideits samba container like this:
docker run --rm -v $(which docker):/docker -v /var/run/docker.sock:/docker.sock svendowideit/samba <container name>
It's possible to do if you use volume instead of filesystem path. It's created for you automatically, if it already doesn't exist.
docker run -d -v usr_share_wordpress:/usr/share/wordpress --name your_container ... image
After you stop or remove your container, your volume will be stored on your filesystem with files from container.
You can inspect volume content during lifetime of your_container with busybox image. Something like:
docker run -it --rm --volumes-from your_container busybox sh
After shutdown of your_container you can still check volume with:
docker run -it --rm -v usr_share_wordpress:/usr/share/wordpress busybox sh
List volumes with docker volume ls.
I had a similar need of exposing the files from container to the host. There is an open issue on this as of today. One of the work-arounds mentioned, using binds, is pretty neat; it works when the container is up and running:
container_root=$(docker inspect --format {{.State.Pid}} "$container_name")/root
sudo bindfs --map=root/"$USER" "$container_root/$app_folder" "$host_folder"
PS: I am not sure this is good for production, but it should work in development scenarios!
Why not just do: docker run ... -v /usr/share/wordpress/:/usr/share/wordpress. Now your local /usr/share/wordpress/ is mapped to /usr/share/wordpress in the Docker container and both have the same files. You could also mount elsewhere in the container this way. The syntax is host_path:container_path, so if you wanted to mount /usr/share/wordpress from your host to /my/new/path on the container, you'd just do: docker run ... -v /usr/share/wordpress/:/my/new/path.