Open sc250024 opened 6 days ago
Would someone from Bitnami be willing to answer any questions here to address this issue?
I've been digging through the code recently looking for a hook where I can run a custom script to do a post wordpress install of plugins/themes after an init. I was planning on using Composer (https://getcomposer.org/) to do this install and run some custom wp-cli commands. After much digging I'm unable to find such a hook.
A script placed inside /docker-entrypoint-initdb.d runs before the persistent install of WordPress so is unhelpful for me in this case. I'm pretty sure there's an intention to run custom post-install scripts as I do see the /post-init.d folder on the container and the code inside post-init.sh seems to indicate it's wishing to load all the .sh files from that folder and run them. However, when I place a 775 file.sh into that folder it does not execute at all.
So there's possibly a bug there, or perhaps it wasn't designed to do what I'm wishing it to do. The docs don't really speak to this area and does require some code digging to understand.
To your point @sc250024 I to had a challenges getting it to work. I'm running on Openshift which requires a rootless container, hence the reason I generally default back to Bitnami images (which I love BTW!)
I eventually got it to work, with a great deal of trial and error to understand the inner workings of the image. I'd agree that some additional documentation would be helpful for some, depending on your use case you may have to go code digging anyway, especially if it's more of an edge case.
@bashbang I am currently doing something like this for my custom theme:
I actually don't mind building the custom image and pushing it, but I think there should be some documentation around this.
Thank you for bringing this issue to our attention. We appreciate your involvement!
The recommended way of consuming this container in Kubernetes is using the bitnami/wordpress Helm chart. There are different blog posts about how Bitnami containers and Helm charts are securitized, i.e
Having said that, if you're interested in contributing a solution to improve the docs, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.
Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.
@bashbang I am currently doing something like this for my custom theme:
Dockerfile I actually don't mind building the custom image and pushing it, but I think there should be some documentation around this.
@sc250024 This was very helpful thank you. I'd tried do use this method in a previous version of my Dockerfile but the content kept getting overwritten. I suspect incorrect permissions or ownership was the reason.
In any case adding the composer.json file to the /opt/bitnami/wordpress/ folder then running the "composer update" while doing the docker build places the plugins and themes into the /opt/bitnami/wordpress folder which then during the runtime init moves the files into the /bitnami/wordpress/wp-content subfolders.
So thank you for the tip....it helped and got me moving in the right direction.
@carrodher Hey Carlos! The Helm chart does help, but it also needs improvements. For example, if I run a simple helm template
command on the latest version of the bitnami/wordpress
chart, the volumeMounts
section is as follows:
volumeMounts:
- name: empty-dir
mountPath: /opt/bitnami/apache/conf
subPath: apache-conf-dir
- name: empty-dir
mountPath: /opt/bitnami/apache/logs
subPath: apache-logs-dir
- name: empty-dir
mountPath: /opt/bitnami/apache/var/run
subPath: apache-tmp-dir
- name: empty-dir
mountPath: /opt/bitnami/php/etc
subPath: php-conf-dir
- name: empty-dir
mountPath: /opt/bitnami/php/tmp
subPath: php-tmp-dir
- name: empty-dir
mountPath: /opt/bitnami/php/var
subPath: php-var-dir
- name: empty-dir
mountPath: /tmp
subPath: tmp-dir
- name: empty-dir
mountPath: /opt/bitnami/wordpress
subPath: app-base-dir
- mountPath: /bitnami/wordpress
name: wordpress-data
subPath: wordpress
Why are all these paths needed?
Also, this works fine if you're using Apache, but there seems to be no support for the NGINX image in that chart. Additionally, if I run a simple helm install
with default settings, I noticed this in the logs of the Wordpress container:
06:06:02.74 INFO ==> ** Starting WordPress setup **
06:06:02.74 WARN ==> The Apache configuration file '/opt/bitnami/apache/conf/httpd.conf' is not writable. Configurations based on environment variables will not be applied.
06:06:02.75 INFO ==> Generating sample certificates
So even with the defaults, there are still permission issues.
@carrodher Do you know the processes that the image goes through during startup?
Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.
For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:
These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.
@carrodher I am very well versed in Kubernetes, and with running non-root containers. The links you sent, while informative, I think are too generic for this issue. I am wondering what steps / processes this particular image does to ensure that that the processes all start correctly, and that WordPress is setup for a non-root container environment.
I would ping people who have contributed to the changes on each file, but a git blame
simply reveals the only code author to be the @bitnami-bot (example here)
It sounds like what you're saying is that I would need to look through all of these scripts myself to fix the problem? There's no one in your organization with this deeper level of knowledge? Is that correct?
Name and Version
bitnami/wordpress-nginx:6.5.5-debian-12-r2
What is the problem this feature will solve?
Currently there is a dearth of documentation around how the Bitnami Wordpress / Wordpress NGINX container images work under the hood; specifically, what they are doing at runtime in order to install WordPress, and how to deal with this running in a more secure Kubernetes environment. Because of this, users like me are having a hell of a time trying to get the Bitnami Wordpress images to work in a Kubernetes environment that's more locked down.
What is the feature you are proposing to solve the problem?
I would like to use this issue to make the following improvements:
bitnami/wordpress
andbitnami/wordpress-nginx
container image documentation to contain detailed information on what each image does during runtime (if it doesn't already).bitnami/wordpress
andbitnami/wordpress-nginx
container image documentation to contain instructions for adding custom themes / plugins in a custom image (if it doesn't already).I will myself open the PR to do the documentation updates, but I am looking for a member of Bitnami to assist with technical questions.
What alternatives have you considered?
Using the official WordPress image on DockerHub (https://hub.docker.com/_/wordpress) because even though it does not contain nearly as many helpers, at least I control what's going on during runtime, and can find workarounds to security restrictions.