![\"\"](\"https:\/\/blog.openshift.one\/wp-content\/uploads\/2023\/05\/wordpress-ocpv.png\")
<\/figure>\n\n\n\nTo make the exercise more interesting I decided that every single step will be done in CLI. In general, depends on the task it may be convenient to use either WebUI or command line but in this case I will focus only on text console. <\/p>\n\n\n\n
Requirements:<\/h3>\n\n\n\n\n- Running OpenShift Container Platform (https:\/\/docs.openshift.com\/container-platform\/4.12\/getting_started\/openshift-overview.html<\/a>)<\/li>\n\n\n\n
- Installed and running OpenShift Virtualisation Operator (https:\/\/docs.openshift.com\/container-platform\/4.12\/virt\/about-virt.html<\/a>)<\/li>\n\n\n\n
- Installed and running OpenShift Data Foundation Operator (https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_openshift_data_foundation\/4.12<\/a>)<\/li>\n\n\n\n
- Working end exposed internal OpenShift Image Registry (https:\/\/docs.openshift.com\/container-platform\/4.12\/registry\/securing-exposing-registry.html<\/a>)<\/li>\n\n\n\n
- Installed
oc<\/code> and virtctl<\/code> CLI tools (https:\/\/docs.openshift.com\/container-platform\/4.12\/cli_reference\/openshift_cli\/getting-started-cli.html<\/a>)<\/li>\n<\/ul>\n\n\n\n<\/div>\n\n\n\nProject wordpress-demo<\/h3>\n\n\n\n
Firstly I will create a new project called wordpress-demo<\/em> where the blog application will be running:<\/p>\n\n\n\n$ oc new-project wordpress-demo\nNow using project \"wordpress-demo\" on server \"https:\/\/api.ocp4.example.com:6443\".\n\nYou can add applications to this project with the 'new-app' command. For example, try:\n\n oc new-app rails-postgresql-example\n\nto build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:\n\n kubectl create deployment hello-node --image=k8s.gcr.io\/e2e-test-images\/agnhost:2.33 -- \/agnhost serve-hostname<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nCreating VM in OpenShift<\/h3>\n\n\n\n
When creating virtual machine in OpenShift using WebUI is much more convenient than CLI, but I believe knowing the both ways is the best option. I use OpenShift’s template rhel9-server-small<\/em> from openshift<\/em> namespace to create simple VM with RHEL9. These templates among the others come out of the box with OpenShift Virtualization operator. Please note the VM is not automatically started after creation:<\/p>\n\n\n\n$ oc process -n openshift rhel9-server-small -p NAME=wordpress-db | oc create -f -\nvirtualmachine.kubevirt.io\/wordpress-db created\n\n$ oc get vm\nNAME AGE STATUS READY\nwordpress-db 25s Stopped False\n\n$ virtctl start wordpress-db\nVM wordpress-db was scheduled to start\n\n$ oc get vm,vmi\nNAME AGE STATUS READY\nvirtualmachine.kubevirt.io\/wordpress-db 70s Running True\n\nNAME AGE PHASE IP NODENAME READY\nvirtualmachineinstance.kubevirt.io\/wordpress-db 28s Running 10.129.1.104 master-1 True<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nVirtual machine user credentials<\/h3>\n\n\n\n
Because I didn’t specify CLOUD_USER_PASSWORD<\/code> parameter while processing the template and creating the VM, cloud_user <\/em>password has been automatically generated for me. I could retrieve it in various ways but this time I want to challenge myself and do everything in CLI, therefore I ran the following command to get it from the VM resource:<\/p>\n\n\n\n$ oc get vm wordpress-db -o json | jq -r '.spec.template.spec.volumes[] | select(.name | contains(\"cloudinitdisk\")) | .cloudInitNoCloud.userData'\n#cloud-config\nuser: cloud-user\npassword: maa1-4jpj-6m77\nchpasswd: { expire: False }<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nConnecting to the VM<\/h3>\n\n\n\n
To get access to the VM console I use virtctl<\/code> CLI tool and credentials from the above. Once I got in I enabled password authentication for sshd and restarted it so I can ssh to the VM directly:<\/p>\n\n\n\n$ virtctl console wordpress-db\nSuccessfully connected to wordpress-db console. The escape sequence is ^]\n\nwordpress-db login: cloud-user\nPassword:\n[cloud-user@wordpress-db ~]$ sudo su\n\n[root@wordpress-db ~]# sed -i 's\/^PasswordAuthentication no\/\/g' \/etc\/ssh\/sshd_config\n\n[root@wordpress-db ~]# systemctl restart sshd<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBut… wait a moment! How am I supposed to ssh there?
Since VM in OpenShift Virtualisation is running in a container it inherits network attachments too. I don’t have any extra networks defined here so I will use NodePort<\/a> service type in order to get connected to the VM. virtctl<\/code> tool is very handy to create it for a virtual machine:<\/p>\n\n\n\n$ virtctl expose vm wordpress-db --port=22 --name=wordpress-db-ssh --type=NodePort\nService wordpress-db-ssh successfully exposed for vm wordpress-db<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nSince I use a NodePort, OpenShift creates for me random port forwarding rule on all the nodes running in the cluster to let me access the VM. The random port number can be retrieved from service definition:<\/p>\n\n\n\n
$ oc get svc wordpress-db-ssh\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nwordpress-db-ssh NodePort<\/strong> 172.30.31.216 <none> 22:32163<\/strong>\/TCP 3m5s<\/code><\/pre>\n\n\n\nor in a bit more fancy way:<\/p>\n\n\n\n
$ oc get svc wordpress-db-ssh -o json | jq '.spec.ports[] | select(.port | contains(22)).nodePort'\n32163<\/strong><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nNow I need the IP address to connect to. Since this is NodePort type service we can connect to any of the nodes in the cluster and the connection will be redirected through default cluster network to the VM. Let’s get the IPs of all nodes:<\/p>\n\n\n\n
$ oc get nodes -o custom-columns=NODE:.metadata.name,IP:.status.addresses[].address\nNODE IP\nmaster-1 192.168.232.123<\/strong>\nmaster-2 192.168.232.124<\/strong>\nmaster-3 192.168.232.122<\/strong><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nWith IP address and port number I can finally get access to the VM:<\/p>\n\n\n\n
$ ssh cloud-user@192.168.232.123 -p 32163\ncloud-user@192.168.232.123's password:\nRegister this system with Red Hat Insights: insights-client --register\nCreate an account or view all your systems at https:\/\/red.ht\/insights-dashboard\n[cloud-user@wordpress-db ~]$<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBecause it is just another virtual machine running under QEMU-KVM, there is nothing really new for those familiar with virtualisation. Let’s get it registered with Red Hat and install MariaDB on it, preferably this should be done with some sort of automation but that’s not the aim for this practice.<\/p>\n\n\n\n
[cloud-user@wordpress-db ~]$ sudo subscription-manager register --org <<ORG_ID>> --activationkey <<KEY>>\nThe system has been registered with ID: aaa-eee-ffff-ccc\nThe registered system name is: wordpress-db\nInstalled Product Current Status:\nProduct Name: Red Hat Enterprise Linux for x86_64\nStatus: Subscribed\n\n[cloud-user@wordpress-db ~]$ sudo dnf install -y mariadb-server\nUpdating Subscription Management repositories.\nRed Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) 9.4 MB\/s | 21 MB 00:02\nRed Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)\n(...)\nComplete!\n\n[cloud-user@wordpress-db ~]$ sudo systemctl enable --now mariadb\nCreated symlink \/etc\/systemd\/system\/mysql.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.\nCreated symlink \/etc\/systemd\/system\/mysqld.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.\nCreated symlink \/etc\/systemd\/system\/multi-user.target.wants\/mariadb.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nCreate a database and a user wordpress_user<\/code> with password wordpress_password<\/code>. Please write down that somewhere as it will be needed when configuring WordPress.<\/p>\n\n\n\n[cloud-user@wordpress-db ~]$ echo \"create database wordpress; grant all on wordpress.* to 'wordpress_user'@'%' identified by 'wordpress_password'; flush privileges;\" | sudo mysql<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nThe last thing I still need to do is exposing MariaDB port so pods (containers) can access it. Again I will use virtctl<\/code> CLI. Please note missing --type=NodePort<\/code> parameter. This is because the default type (ClusterIP<\/em>) is enough as we don’t expect – at least now – to have a need to connect to MariaDB from outside the cluster.<\/p>\n\n\n\n$ virtctl expose vm wordpress-db --port=3306 --name=wordpress-db-mariadb\nService wordpress-db-mariadb successfully exposed for vm wordpress-db\n\n$ oc describe svc wordpress-db-mariadb\nName: wordpress-db-mariadb\nNamespace: wordpress-demo\nLabels: <none>\nAnnotations: <none>\nSelector: kubevirt.io\/domain=wordpress-db,kubevirt.io\/size=small\nType: ClusterIP\nIP Family Policy: SingleStack\nIP Families: IPv4\nIP: 172.30.106.220\nIPs: 172.30.106.220\nPort: <unset> 3306\/TCP\nTargetPort: 3306\/TCP\nEndpoints: 10.129.1.104:3306\nSession Affinity: None\nEvents: <none><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nThe virtual machine is ready now, let’s do some containerisation work.<\/p>\n\n\n\n
<\/div>\n\n\n\nContainers – original WordPress image<\/h3>\n\n\n\n
WordPress provides official Docker image available at https:\/\/hub.docker.com\/_\/wordpress to speedup the process a bit. It contains integration making running it in a container straightforward but… let me show you.<\/p>\n\n\n\n
I created a deploymend using oc new-app<\/code> command as bellow:<\/p>\n\n\n\n$ oc new-app --image=docker.io\/wordpress:php8.2-apache --name=wordpress-frontend -e WORDPRESS_DB_HOST=wordpress-db-mariadb -e WORDPRESS_DB_USER=wordpress_user -e WORDPRESS_DB_PASSWORD=wordpress_password -e WORDPRESS_DB_NAME=wordpress\n--> Found container image 5835e3b (32 hours old) from docker.io for \"docker.io\/wordpress:php8.2-apache\"\n\n * An image stream tag will be created as \"wordpress-frontend:php8.2-apache\" that will track this image\n\n--> Creating resources ...\n imagestream.image.openshift.io \"wordpress-frontend\" created\nWarning: would violate PodSecurity \"restricted:v1.24\": allowPrivilegeEscalation != false (container \"wordpress-frontend\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"wordpress-frontend\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"wordpress-frontend\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"wordpress-frontend\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")\n deployment.apps \"wordpress-frontend\" created\n service \"wordpress-frontend\" created\n--> Success\n Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:\n 'oc expose service\/wordpress-frontend'\n Run 'oc status' to view your app.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nSo far so good, let me check the app status as the command above suggest:<\/p>\n\n\n\n
$ oc status\nIn project wordpress-demo on server https:\/\/api.ocp4.example.com:6443\n\nsvc\/wordpress-db-ssh (all nodes):32163 -> 22\nsvc\/wordpress-db-mariadb - 172.30.106.220:3306\n pod\/virt-launcher-wordpress-db-75b8w runs registry.redhat.io\/container-native-virtualization\/virt-launcher@sha256:1ee29ef3f8b117bef13ba4325b597da99b55a1acb5f2e9eabe11937e9314fe73\n\nsvc\/wordpress-frontend - 172.30.78.10:80\n deployment\/wordpress-frontend deploys istag\/wordpress-frontend:php8.2-apache\n deployment #2 running for about a minute - 0\/1 pods (warning: 3 restarts)\n deployment #1 deployed about a minute ago\n\nErrors:\n * pod\/wordpress-frontend-5d467d8899-wn8v9 is crash-looping\n\n1 error, 1 info identified, use 'oc status --suggest' to see details.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nOoops! The pod is crash-looping what indicates successful download\/import to the cluster but while running it fails for some unknown yet reason. Let’s see what OpenShift would suggest me to do:<\/p>\n\n\n\n
$ oc status --suggest\n(...)\nErrors:\n * pod\/wordpress-frontend-5d467d8899-wn8v9 is crash-looping\n\n The container is starting and exiting repeatedly. This usually means the container is unable\n to start, misconfigured, or limited by security restrictions. Check the container logs with\n\n oc logs wordpress-frontend-5d467d8899-wn8v9 -c wordpress-frontend\n\n Current security policy prevents your containers from being run as the root user. Some images\n may fail expecting to be able to change ownership or permissions on directories. Your admin\n can grant you access to run containers that need to run as the root user with this command:\n\n oc adm policy add-scc-to-user anyuid -n wordpress-demo -z default\n(...)<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nOk that may be the case. I don’t like the advice though to level up privileges. Let’s investigate it further and check for any output logs on the container:<\/p>\n\n\n\n
$ oc logs wordpress-frontend-5d467d8899-wn8v9 -c wordpress-frontend\nAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.129.1.49. Set the 'ServerName' directive globally to suppress this message\n(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80\n(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80\nno listening sockets available, shutting down\nAH00015: Unable to open logs<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nGotcha! As you can see, the wordpress image wants to bind to port 80\/tcp for what it would require extra privileges. This isn’t something what I’d like to have running on my cluster due to the obvious security concerns. Therefore I will slightly modify the original docker image and adapt it for being used on OpenShift. Simultaneously I will increase its security level too! \ud83d\ude09 <\/p>\n\n\n\n
<\/div>\n\n\n\nContainers – custom WordPress image<\/h3>\n\n\n\n
Firstly let’s clean up the failed deployment to ensure it won’t interfere in any way with the later one.<\/p>\n\n\n\n
$ oc delete all -l app=wordpress-frontend\nservice \"wordpress-frontend\" deleted\ndeployment.apps \"wordpress-frontend\" deleted\nimagestream.image.openshift.io \"wordpress-frontend\" deleted<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBecause container images are layered, I can use the original image – docker.io\/wordpress:php8.2-apache<\/code> – and apply some changes to it to produce new, custom one. I’ve quickly reviewed what’s inside the original image and how its original Dockerfile looks like. This brought me to the conclusion that the following simple Containerfile will fix the issue and let me run WordPress container as unprivileged. I use podman instead of docker, hence I use Containerfile in place of Dockerfile, the syntax is the same:<\/p>\n\n\n\n$ cat << EOF > Containerfile\nFROM docker.io\/wordpress:php8.2-apache\n\nRUN sed -i 's\/^Listen\\ 80$\/Listen\\ 8080\/' \/etc\/apache2\/ports.conf\n\nEXPOSE 8080\nENTRYPOINT [\"\/usr\/local\/bin\/docker-entrypoint.sh\"]\nCMD [\"apache2-foreground\"]\nEOF<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nNow I will build and tag the image. I’m using my OpenShift’s internal registry route which let me upload images from outside the cluster:<\/p>\n\n\n\n
$ podman build -t default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress .\nSTEP 1\/5: FROM docker.io\/wordpress:php8.2-apache\nSTEP 2\/5: RUN sed -i 's\/^Listen\\ 80$\/Listen\\ 8080\/' \/etc\/apache2\/ports.conf\n--> c511c5645d3\nSTEP 3\/5: EXPOSE 8080\n--> 3a27ae7062a\nSTEP 4\/5: ENTRYPOINT [\"\/usr\/local\/bin\/docker-entrypoint.sh\"]\n--> d75fd350f4a\nSTEP 5\/5: CMD [\"apache2-foreground\"]\nCOMMIT default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress\n--> 945945a1c24\nSuccessfully tagged default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress:latest\n945945a1c24a9e8620d33c2eca01a98e1d796911868536dcf32c9ac92843e3cc<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nHow to configure external access for OpenShift internal image registry you can find in this document: https:\/\/docs.openshift.com\/container-platform\/4.12\/registry\/securing-exposing-registry.html<\/a><\/p>\n\n\n\nTime to push the image to the registry:<\/p>\n\n\n\n
$ podman push default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress\nGetting image source signatures\n(...)\nCopying blob f675495821b9 done\n(...)\nCopying config 945945a1c2 done\nWriting manifest to image destination\nStoring signatures<\/code><\/pre>\n\n\n\n
oc<\/code> and virtctl<\/code> CLI tools (https:\/\/docs.openshift.com\/container-platform\/4.12\/cli_reference\/openshift_cli\/getting-started-cli.html<\/a>)<\/li>\n<\/ul>\n\n\n\n<\/div>\n\n\n\nProject wordpress-demo<\/h3>\n\n\n\n
Firstly I will create a new project called wordpress-demo<\/em> where the blog application will be running:<\/p>\n\n\n\n$ oc new-project wordpress-demo\nNow using project \"wordpress-demo\" on server \"https:\/\/api.ocp4.example.com:6443\".\n\nYou can add applications to this project with the 'new-app' command. For example, try:\n\n oc new-app rails-postgresql-example\n\nto build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:\n\n kubectl create deployment hello-node --image=k8s.gcr.io\/e2e-test-images\/agnhost:2.33 -- \/agnhost serve-hostname<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nCreating VM in OpenShift<\/h3>\n\n\n\n
When creating virtual machine in OpenShift using WebUI is much more convenient than CLI, but I believe knowing the both ways is the best option. I use OpenShift’s template rhel9-server-small<\/em> from openshift<\/em> namespace to create simple VM with RHEL9. These templates among the others come out of the box with OpenShift Virtualization operator. Please note the VM is not automatically started after creation:<\/p>\n\n\n\n$ oc process -n openshift rhel9-server-small -p NAME=wordpress-db | oc create -f -\nvirtualmachine.kubevirt.io\/wordpress-db created\n\n$ oc get vm\nNAME AGE STATUS READY\nwordpress-db 25s Stopped False\n\n$ virtctl start wordpress-db\nVM wordpress-db was scheduled to start\n\n$ oc get vm,vmi\nNAME AGE STATUS READY\nvirtualmachine.kubevirt.io\/wordpress-db 70s Running True\n\nNAME AGE PHASE IP NODENAME READY\nvirtualmachineinstance.kubevirt.io\/wordpress-db 28s Running 10.129.1.104 master-1 True<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nVirtual machine user credentials<\/h3>\n\n\n\n
Because I didn’t specify CLOUD_USER_PASSWORD<\/code> parameter while processing the template and creating the VM, cloud_user <\/em>password has been automatically generated for me. I could retrieve it in various ways but this time I want to challenge myself and do everything in CLI, therefore I ran the following command to get it from the VM resource:<\/p>\n\n\n\n$ oc get vm wordpress-db -o json | jq -r '.spec.template.spec.volumes[] | select(.name | contains(\"cloudinitdisk\")) | .cloudInitNoCloud.userData'\n#cloud-config\nuser: cloud-user\npassword: maa1-4jpj-6m77\nchpasswd: { expire: False }<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nConnecting to the VM<\/h3>\n\n\n\n
To get access to the VM console I use virtctl<\/code> CLI tool and credentials from the above. Once I got in I enabled password authentication for sshd and restarted it so I can ssh to the VM directly:<\/p>\n\n\n\n$ virtctl console wordpress-db\nSuccessfully connected to wordpress-db console. The escape sequence is ^]\n\nwordpress-db login: cloud-user\nPassword:\n[cloud-user@wordpress-db ~]$ sudo su\n\n[root@wordpress-db ~]# sed -i 's\/^PasswordAuthentication no\/\/g' \/etc\/ssh\/sshd_config\n\n[root@wordpress-db ~]# systemctl restart sshd<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBut… wait a moment! How am I supposed to ssh there?
Since VM in OpenShift Virtualisation is running in a container it inherits network attachments too. I don’t have any extra networks defined here so I will use NodePort<\/a> service type in order to get connected to the VM. virtctl<\/code> tool is very handy to create it for a virtual machine:<\/p>\n\n\n\n$ virtctl expose vm wordpress-db --port=22 --name=wordpress-db-ssh --type=NodePort\nService wordpress-db-ssh successfully exposed for vm wordpress-db<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nSince I use a NodePort, OpenShift creates for me random port forwarding rule on all the nodes running in the cluster to let me access the VM. The random port number can be retrieved from service definition:<\/p>\n\n\n\n
$ oc get svc wordpress-db-ssh\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nwordpress-db-ssh NodePort<\/strong> 172.30.31.216 <none> 22:32163<\/strong>\/TCP 3m5s<\/code><\/pre>\n\n\n\nor in a bit more fancy way:<\/p>\n\n\n\n
$ oc get svc wordpress-db-ssh -o json | jq '.spec.ports[] | select(.port | contains(22)).nodePort'\n32163<\/strong><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nNow I need the IP address to connect to. Since this is NodePort type service we can connect to any of the nodes in the cluster and the connection will be redirected through default cluster network to the VM. Let’s get the IPs of all nodes:<\/p>\n\n\n\n
$ oc get nodes -o custom-columns=NODE:.metadata.name,IP:.status.addresses[].address\nNODE IP\nmaster-1 192.168.232.123<\/strong>\nmaster-2 192.168.232.124<\/strong>\nmaster-3 192.168.232.122<\/strong><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nWith IP address and port number I can finally get access to the VM:<\/p>\n\n\n\n
$ ssh cloud-user@192.168.232.123 -p 32163\ncloud-user@192.168.232.123's password:\nRegister this system with Red Hat Insights: insights-client --register\nCreate an account or view all your systems at https:\/\/red.ht\/insights-dashboard\n[cloud-user@wordpress-db ~]$<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBecause it is just another virtual machine running under QEMU-KVM, there is nothing really new for those familiar with virtualisation. Let’s get it registered with Red Hat and install MariaDB on it, preferably this should be done with some sort of automation but that’s not the aim for this practice.<\/p>\n\n\n\n
[cloud-user@wordpress-db ~]$ sudo subscription-manager register --org <<ORG_ID>> --activationkey <<KEY>>\nThe system has been registered with ID: aaa-eee-ffff-ccc\nThe registered system name is: wordpress-db\nInstalled Product Current Status:\nProduct Name: Red Hat Enterprise Linux for x86_64\nStatus: Subscribed\n\n[cloud-user@wordpress-db ~]$ sudo dnf install -y mariadb-server\nUpdating Subscription Management repositories.\nRed Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) 9.4 MB\/s | 21 MB 00:02\nRed Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)\n(...)\nComplete!\n\n[cloud-user@wordpress-db ~]$ sudo systemctl enable --now mariadb\nCreated symlink \/etc\/systemd\/system\/mysql.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.\nCreated symlink \/etc\/systemd\/system\/mysqld.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.\nCreated symlink \/etc\/systemd\/system\/multi-user.target.wants\/mariadb.service \u2192 \/usr\/lib\/systemd\/system\/mariadb.service.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nCreate a database and a user wordpress_user<\/code> with password wordpress_password<\/code>. Please write down that somewhere as it will be needed when configuring WordPress.<\/p>\n\n\n\n[cloud-user@wordpress-db ~]$ echo \"create database wordpress; grant all on wordpress.* to 'wordpress_user'@'%' identified by 'wordpress_password'; flush privileges;\" | sudo mysql<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nThe last thing I still need to do is exposing MariaDB port so pods (containers) can access it. Again I will use virtctl<\/code> CLI. Please note missing --type=NodePort<\/code> parameter. This is because the default type (ClusterIP<\/em>) is enough as we don’t expect – at least now – to have a need to connect to MariaDB from outside the cluster.<\/p>\n\n\n\n$ virtctl expose vm wordpress-db --port=3306 --name=wordpress-db-mariadb\nService wordpress-db-mariadb successfully exposed for vm wordpress-db\n\n$ oc describe svc wordpress-db-mariadb\nName: wordpress-db-mariadb\nNamespace: wordpress-demo\nLabels: <none>\nAnnotations: <none>\nSelector: kubevirt.io\/domain=wordpress-db,kubevirt.io\/size=small\nType: ClusterIP\nIP Family Policy: SingleStack\nIP Families: IPv4\nIP: 172.30.106.220\nIPs: 172.30.106.220\nPort: <unset> 3306\/TCP\nTargetPort: 3306\/TCP\nEndpoints: 10.129.1.104:3306\nSession Affinity: None\nEvents: <none><\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nThe virtual machine is ready now, let’s do some containerisation work.<\/p>\n\n\n\n
<\/div>\n\n\n\nContainers – original WordPress image<\/h3>\n\n\n\n
WordPress provides official Docker image available at https:\/\/hub.docker.com\/_\/wordpress to speedup the process a bit. It contains integration making running it in a container straightforward but… let me show you.<\/p>\n\n\n\n
I created a deploymend using oc new-app<\/code> command as bellow:<\/p>\n\n\n\n$ oc new-app --image=docker.io\/wordpress:php8.2-apache --name=wordpress-frontend -e WORDPRESS_DB_HOST=wordpress-db-mariadb -e WORDPRESS_DB_USER=wordpress_user -e WORDPRESS_DB_PASSWORD=wordpress_password -e WORDPRESS_DB_NAME=wordpress\n--> Found container image 5835e3b (32 hours old) from docker.io for \"docker.io\/wordpress:php8.2-apache\"\n\n * An image stream tag will be created as \"wordpress-frontend:php8.2-apache\" that will track this image\n\n--> Creating resources ...\n imagestream.image.openshift.io \"wordpress-frontend\" created\nWarning: would violate PodSecurity \"restricted:v1.24\": allowPrivilegeEscalation != false (container \"wordpress-frontend\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"wordpress-frontend\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"wordpress-frontend\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"wordpress-frontend\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")\n deployment.apps \"wordpress-frontend\" created\n service \"wordpress-frontend\" created\n--> Success\n Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:\n 'oc expose service\/wordpress-frontend'\n Run 'oc status' to view your app.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nSo far so good, let me check the app status as the command above suggest:<\/p>\n\n\n\n
$ oc status\nIn project wordpress-demo on server https:\/\/api.ocp4.example.com:6443\n\nsvc\/wordpress-db-ssh (all nodes):32163 -> 22\nsvc\/wordpress-db-mariadb - 172.30.106.220:3306\n pod\/virt-launcher-wordpress-db-75b8w runs registry.redhat.io\/container-native-virtualization\/virt-launcher@sha256:1ee29ef3f8b117bef13ba4325b597da99b55a1acb5f2e9eabe11937e9314fe73\n\nsvc\/wordpress-frontend - 172.30.78.10:80\n deployment\/wordpress-frontend deploys istag\/wordpress-frontend:php8.2-apache\n deployment #2 running for about a minute - 0\/1 pods (warning: 3 restarts)\n deployment #1 deployed about a minute ago\n\nErrors:\n * pod\/wordpress-frontend-5d467d8899-wn8v9 is crash-looping\n\n1 error, 1 info identified, use 'oc status --suggest' to see details.<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nOoops! The pod is crash-looping what indicates successful download\/import to the cluster but while running it fails for some unknown yet reason. Let’s see what OpenShift would suggest me to do:<\/p>\n\n\n\n
$ oc status --suggest\n(...)\nErrors:\n * pod\/wordpress-frontend-5d467d8899-wn8v9 is crash-looping\n\n The container is starting and exiting repeatedly. This usually means the container is unable\n to start, misconfigured, or limited by security restrictions. Check the container logs with\n\n oc logs wordpress-frontend-5d467d8899-wn8v9 -c wordpress-frontend\n\n Current security policy prevents your containers from being run as the root user. Some images\n may fail expecting to be able to change ownership or permissions on directories. Your admin\n can grant you access to run containers that need to run as the root user with this command:\n\n oc adm policy add-scc-to-user anyuid -n wordpress-demo -z default\n(...)<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nOk that may be the case. I don’t like the advice though to level up privileges. Let’s investigate it further and check for any output logs on the container:<\/p>\n\n\n\n
$ oc logs wordpress-frontend-5d467d8899-wn8v9 -c wordpress-frontend\nAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.129.1.49. Set the 'ServerName' directive globally to suppress this message\n(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80\n(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80\nno listening sockets available, shutting down\nAH00015: Unable to open logs<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nGotcha! As you can see, the wordpress image wants to bind to port 80\/tcp for what it would require extra privileges. This isn’t something what I’d like to have running on my cluster due to the obvious security concerns. Therefore I will slightly modify the original docker image and adapt it for being used on OpenShift. Simultaneously I will increase its security level too! \ud83d\ude09 <\/p>\n\n\n\n
<\/div>\n\n\n\nContainers – custom WordPress image<\/h3>\n\n\n\n
Firstly let’s clean up the failed deployment to ensure it won’t interfere in any way with the later one.<\/p>\n\n\n\n
$ oc delete all -l app=wordpress-frontend\nservice \"wordpress-frontend\" deleted\ndeployment.apps \"wordpress-frontend\" deleted\nimagestream.image.openshift.io \"wordpress-frontend\" deleted<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nBecause container images are layered, I can use the original image – docker.io\/wordpress:php8.2-apache<\/code> – and apply some changes to it to produce new, custom one. I’ve quickly reviewed what’s inside the original image and how its original Dockerfile looks like. This brought me to the conclusion that the following simple Containerfile will fix the issue and let me run WordPress container as unprivileged. I use podman instead of docker, hence I use Containerfile in place of Dockerfile, the syntax is the same:<\/p>\n\n\n\n$ cat << EOF > Containerfile\nFROM docker.io\/wordpress:php8.2-apache\n\nRUN sed -i 's\/^Listen\\ 80$\/Listen\\ 8080\/' \/etc\/apache2\/ports.conf\n\nEXPOSE 8080\nENTRYPOINT [\"\/usr\/local\/bin\/docker-entrypoint.sh\"]\nCMD [\"apache2-foreground\"]\nEOF<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nNow I will build and tag the image. I’m using my OpenShift’s internal registry route which let me upload images from outside the cluster:<\/p>\n\n\n\n
$ podman build -t default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress .\nSTEP 1\/5: FROM docker.io\/wordpress:php8.2-apache\nSTEP 2\/5: RUN sed -i 's\/^Listen\\ 80$\/Listen\\ 8080\/' \/etc\/apache2\/ports.conf\n--> c511c5645d3\nSTEP 3\/5: EXPOSE 8080\n--> 3a27ae7062a\nSTEP 4\/5: ENTRYPOINT [\"\/usr\/local\/bin\/docker-entrypoint.sh\"]\n--> d75fd350f4a\nSTEP 5\/5: CMD [\"apache2-foreground\"]\nCOMMIT default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress\n--> 945945a1c24\nSuccessfully tagged default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress:latest\n945945a1c24a9e8620d33c2eca01a98e1d796911868536dcf32c9ac92843e3cc<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nHow to configure external access for OpenShift internal image registry you can find in this document: https:\/\/docs.openshift.com\/container-platform\/4.12\/registry\/securing-exposing-registry.html<\/a><\/p>\n\n\n\nTime to push the image to the registry:<\/p>\n\n\n\n
$ podman push default-route-openshift-image-registry.apps.ocp4.example.com\/wordpress-demo\/wordpress\nGetting image source signatures\n(...)\nCopying blob f675495821b9 done\n(...)\nCopying config 945945a1c2 done\nWriting manifest to image destination\nStoring signatures<\/code><\/pre>\n\n\n\n
![\"\"](\"https:\/\/blog.openshift.one\/wp-content\/uploads\/2023\/05\/Screenshot-2023-05-18-at-13.13.10.png\")
<\/figure>\n\n\n\n