Get Started with Bitnami containers on OpenShift
OpenShift Online is a container-based platform that can be accessed as a public cloud service. It is designed for individuals and teams that want to deploy a functional Kubernetes cluster on their local computers and use remote services as if they were running locally.
Some of the Bitnami containers have been developed as non-root containers, following the Red Hat guidelines for deploying containers on OpenShift. You can find a wide selection of Bitnami containers in the Red Hat Container Catalog.
This tutorial will walk you through the process of using OpenShift Online to deploy the Bitnami Docker image for WordPress on an OpenShift cluster using an external MariaDB database. Since OpenShift Online offers a free starter plan, you can learn about OpenShift and Bitnami containers and experiment with them without worrying about being billed.
WordPress is one of the most popular blogging platforms in the world, used on over 60 million websites (according to Wikipedia). And it is not hard to see why: WordPress is very easy to use, comes with thousands of extensions and themes, is completely free, and is open source.
This tutorial shows you how to obtain the Bitnami image for WordPress from the Red Hat Container Catalog and how to push it to and deploy it on an OpenShift cluster using an external MariaDB database. But WordPress it is just one example: you can find more Bitnami containers in the Red Hat Container Catalog. They are available for use in the OpenShift deployment model of your choice.
Here are the steps to follow in this tutorial:
- Step 1: Register with OpenShift Online
- Step 2: Create a new project
- Step 3: Obtain the Red Hat MariaDB image and deploy it on OpenShift
- Step 4: Obtain the Bitnami WordPress image and deploy it on OpenShift
- Step 5: Scale up (and down) and perform rolling updates (and rollbacks)
Assumptions and prerequisites
This guide makes the following assumptions:
- You have a basic understanding of Docker containers
- You have a basic understanding of Kubernetes
- You have a Red Hat Customer Portal login
- You have a cluster running on OpenShift
Step 1: Register with OpenShift Online
- At the end of this step, you will have signed up for OpenShift Online with a “Starter Plan” free account. If you already have a Red Hat or OpenShift account, you may skip this step.
- Begin by creating an OpenShift account by browsing https://www.openshift.com/ and clicking on “Learn More” in the Red Hat OpenShift Online deployment option.
You will be redirected to the “Plans & Pricing” page. Select the “Starter Plan” option “Sign up for free”:
On the resulting screen, click on the “Sign up for OpenShift Online” link:
If you already have an OpenShift account, enter your email address or Red Hat login ID and your password. If you don’t, click on the “Create one now” link:
To register for OpenShift Online, fill in the required information in the form, accept the terms and conditions, and click on “Create my account” to proceed.
The next step is to verify your email address. Once you have done so, click on “Confirm Subscription” to confirm your selection and finish the registration.
Congratulations! Your subscription is now active and ready to operate on OpenShift Online!
Step 2: Create a new project
- At the end of this step, you will have created a new project on OpenShift Online.
To start managing containers and creating deployments, you should have, at least, one project created. (Remember that if you chose the “Starter Plan”, the maximum number of projects you can create is just one). Follow these steps to create a new project on OpenShift Online:
Log in to OpenShift Online. Then click “Open Web Console”:
To create a new project, click on the “+ Create Project” button located on the menu on the right side of the screen. This opens a window in which you have to enter a name and a description for the project:
Once the project is created, it will appear on the list of available projects:
If you click on the recently created project, the “Overview” screen appears, showing the different options available. In this case, select “Deploy Image”. Check the step 4 to learn how to add a Bitnami WordPress image to your project.
Step 3: Obtain the Red Hat MariaDB image and deploy it on OpenShift
- At the end of this step, you will have the Red Hat MariaDB image deployed on your OpenShift project, and a MariaDB pod deployed and running on an OpenShift cluster.
To deploy the Red Hat MariaDB image on your OpenShift project, follow these steps:
From the main page of the Web Console, browse the catalog by searching for “MariaDB” to find the available MariaDB images. Select the one you want to deploy.
On the resulting screen, you will find detailed information about the image. Click “Next” to start the deployment.
The next step is to set up all the configuration variables for your image. Select your project, specify the memory limit and choose the namespace in which the image will be deployed.
Continue filling in the form by introducing the environment variables for your database: MariaDB Connection Username, Connection Password, root Password, and Database Name.
Specify other configuration values such as the version of the MariaDB image, and click “Create” to start the image deployment.
Once the cluster is successfully deployed, you can see it on the “Overview” screen.
TIP: You can check the list of the images deployed on your project by navigating to the “Builds -> Images” section.
Navigate to the “Applications -> Deployments” section and click on the new deployment to see its configuration details such as the number of pods, network parameters or memory usage:
Congratulations! You have a OpenShift cluster up and running with one MariaDB container running in one pod.
Step 4: Obtain the Bitnami WordPress image and deploy it on OpenShift
- At the end of this step, you will have the Bitnami WordPress image deployed on your OpenShift project and a WordPress pod running on an OpenShift cluster. Your WordPress application will be connected to the MariaDB pod, that is already running on the cluster, as an external database.
To obtain the Bitnami WordPress image from the Red Hat Container Catalog, follow these steps:
- In the Red Hat Container Catalog main page, enter “Bitnami WordPress” in the search box to find the available Bitnami WordPress images. Select the one you want to deploy.
- From the resulting screen, click on the “Get Latest Image” tab and in the “Choose your platform” menu, select “Red Hat OpenShift”. Copy and save the registry URL as shown below:
The next step is to deploy the Bitnami WordPress image on an OpenShift cluster. To do so, it is necessary to create an image pull secret and connect the deployment to the running MariaDB pod by adding some environment variables.
From the OpenShift Console, click “Add to Project”. Select “Deploy Image”.
On the “Deploy Image” screen, select the “Image Name” option and copy the registry URL you obtained from the Red Hat Container Catalog. Click the mag icon to load the image’s metadata.
To create an image pull secret with your image registry credentials, click on the “create an image pull secret” link found below the “Image Name” field.
Enter a name for the secret and in “Authentication Type” select “Image Registry Credentials”. Then, enter the image registry server address (in this case, it matches with your registry in the Red Hat Container Catalog). Complete the creation of the secret by adding a username, password, and the email address that you used when created your subscription to the Red Hat Container Catalog. Click “Create”:
Now, connect the deployment to the already deployed MariaDB database by adding the following environment variables:
- WORDPRESS_DATABASE_NAME: It must match with the “MariaDB Database Name” value.
- WORDPRESS_DATABASE_USER: It must match with the “MariaDB Connection Username” value.
- WORDPRESS_DATABASE_PASSWORD: It must match with the “MariaDB Connection Password” value.
TIP: You can always check the values of the MariaDB environment variables by clicking on the “ Actions -> Edit YAML” option found in the deployment overview.
- Click “Deploy” to finish the process.
Navigate to the “Overview” section. You will see two pods up and running:
Congratulations! You have an OpenShift cluster running a WordPress pod and connected to a MariaDB pod as an external database.
To access the application, it is necessary to expose a service at a host name, or let the Web Console generate a random one. To do this:
- Navigate to the “Builds -> Routes” section and click “Create Route”.
On the resulting screen, enter a name for the route, a hostname (if you don’t specify it, OpenShift will assign you a random hostname), select the service you want to expose, and change the default target port if needed. Fill in the rest of the options if applicable and click on “Create” to generate the route for your service.
When the route is created, you will obtain a URL to access your application:
Enter the URL directly into your browser address bar. You should see the WordPress home page:
Step 5: Scale up (and down) and perform rolling updates (and rollbacks)
- At the end of this step, you will have explored some of the possibilities that OpenShift Online offers you for managing and automating your clusters. In this example, you will learn how to scale up and down and how to perform updates on your deployments.
Now that your WordPress with MariaDB cluster is deployed, it is time to explore some of the infinite possibilities that OpenShift offers for managing your Kubernetes clusters easily and quickly. First let’s see how to scale your running deployment up and down.
Scale up (and down)
You can scale your deployment up and down from the OpenShift Online Web Console at any time without the need of a terminal.
- To scale your deployment up, click on your deployment on the “Overview” screen to access its information.
On the resulting screen, click on the “Configuration” tab and you will see the deployment configuration. Edit the number of replicas (pods) you want to add to the cluster:
TIP: In the “Configuration” tab, you can select the “Add Autoscaler” option on the right side of the screen. Use this to automate the deployment scaling. You can specify both the minimum and maximum number of replicas that your deployment can add, depending on CPU usage.
If you return to the “Overview” screen, you will see that your deployment has two replicas now. Click on it for more information:
You can scroll down from the same “Deployments” screen. To do so:
- Edit the number of replicas or use the arrows to decrease the number of available pods in your cluster.
- Once you confirm your selection, the deployment will be updated automatically. This process can take a few minutes.
Perform rolling updates (and rollbacks)
To show you how to perform rolling updates and rollbacks, we will add a new environment variable so we will have two different versions of the deployment. Follow these steps:
- Navigate to “Applications -> Deployments” and click on the deployment you want to update. On the resulting screen, select the “Environment” tab.
Scroll down to see the “Environment Variables” section. Click on the “Add Value” link and enter the BITNAMI_APP_NAME variable. Add “wordpress-mariadb-cluster” as the value for that variable. Click on “Save” to execute the changes.
Your deployment will be automatically updated. To check the deployment versions, navigate to the left-hand menu and click on “Applications -> Deployments”.
Click the deployment name to see all the versions available and a summary of the changes made:
To confirm that the new BITNAMI_APP_NAME variable has been added, you can check its YAML file. To do this, select the latest version of the deployment and click “Actions”. Then select “Edit YAML”.
Navigate to the containers environment variable specification. You will see the environment variables added from the Web Console:
Rollbacks are equally simple. Click on the version you want to return to and in the deployment details screen, click on “Roll Back”. This displays a menu with different settings options. Once you have selected the settings, click “Roll Back” to create a new deployment with the same settings as the selected version:
When you view the YAML file to check the environment variables of the new deployment, you will see that revision #2 has been superseded by a copy of revision #1, but this time it is labelled as revision #3.
To learn more about the topics discussed in this guide, use the links below: