In this section, we will show you how to modify the deployment by examining the deployment file (by using kubectl describe deploy/...):

1. You can see that the host value is obtained from the secret, as follows:

MARIADB_HOST: <set to the key 'host' in secret 'osba-quickstart-wordpress-mysql-secret'>

2. To set secrets, we need the base64 value. Obtain the base64 value of the server name by running the following command:

echo <restored db server name> | base64 

Note the base64 value.

3. Get the URI value by running the following command:

kc get -o yaml secrets/osba-quickstart-wordpress-mysql-secret -n osba-quickstart

4. Get the value for URI and decode it using the following command:

echo 'base64 -uri value' | base64 -d

5. Change the server name in the URI string from mysql://username:password@<orig-db-name>.mysql.database.azure.com:3306/k9mhjialu3?useSSL=true&requireSSL=true to mysql://<sameusername>:<same password>@<restored-db-name>.mysql.database.azure.com:3306/k9mhjialu3?useSSL=true&requireSSL=true.
6. Get the encoded value again by running the following command:

echo 'new uri' | base64 -w 0

Note down the new URI value.

7. Run the following command to set the host to the new value:

kubectl edit secrets/osba-quickstart-wordpress-mysql-secret -n osba-quickstart-wordpress

8. Set the value of the host to the Base64 value that you noted down when encoding the restored MySQL server name:

apiVersion: v1
data:
  database: azltaGppYWx1Mw==
  host: <change this value>
  password:...
  uri: <change this value>

9. Save the preceding file by hitting Esc and then :wq.

Even though we have reset the secret value, this doesn't mean that our server will automatically pick up the new value.

10. There are many ways to do it, but we are going to use scaling. Scale down the number of replicas by running the following command:

kc scale --replicas=0 deploy/osba-quickstart-wordpress -n osba-quickstart

11. After waiting 15 minutes, scale the replicas up again:

kc scale --replicas=1 deploy/osba-quickstart-wordpress -n osba-quickstart

Even though, in theory, the preceding should work, if you run the kubectl logs on the WordPress pod, you will see that it is still using the old server name.

This means that logs– has to come from the mounted volume. Running grep -R 'original server name' * on the pod by using kubectl exec shows that the values are actually stored in /bitnami/wordpress/wp-config.php.

12. Open the file and put in the restored database name. Scale the replicas up and down (after waiting for 15 minutes). It might be easier to create a new persistent volume claim (PVC).

The blog logs will show that it is connecting to the restored database.