No results found

Your search did not match any results.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try “application” instead of “software.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions

Deploy a Microservices-Driven Application on Oracle Cloud Infrastructure

This tutorial walks you through the process of deploying and configuring a microservices-driven application on Oracle Cloud Infrastructure (OCI). Here are the main steps:

  1. Create a Kubernetes cluster
  2. Set up the Cloud Shell environment to access the cluster
  3. Deploy the application and verify the deployment
  4. Change the application code and redeploy the application

What you Create

You configure and deploy a set of microservices by using Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). These microservices create a pet store named MuShop.

The following image shows the architecture of the MuShop retail application.

Figure 1. Example of the DevOps process

Figure 1: MuShop pet store retail application architecture

What You Need

To complete this exercise, you need the following resources:

  • An Oracle Cloud Infrastructure tenancy
  • Policies that allow you to create the required resources
  • Capacity availability

Creating a Kubernetes Cluster

In this exercise, you create a cluster by using the Oracle Cloud Infrastructure Console. Using the Console provides a quick way to create a cluster with several defaults automatically applied. For more detailed setup information, and to take more direct control of the resources, see the documentation.

  1. In the Console, open the navigation menu. Under Solutions and Platform, go to Developer Services and click Container Clusters.
  2. Choose the compartment that you prepared for the exercise.
  3. On the Cluster List page, click Create Cluster.
  4. In the Create Cluster dialog box, select Quick Create and click Launch Workflow.
  5. On the Create Cluster page, accept the default configuration details for the cluster.
  6. Click Next to review the details for the cluster.
  7. Click Create Cluster to create the network resources and the cluster.
  8. Wait for the status of the cluster to become Active.

Access the cluster from the Cloud Shell environment

After the cluster is active, you can use standard Kubernetes tools like kubectl and helm to interact with it. For these tools to connect to your cluster, Kubernetes uses a file that contains the cluster access configuration.

In this exercise, you use Oracle Cloud Infrastructure’s Cloud Shell to interact with the cluster. Cloud Shell is a cloud-based terminal that’s preconfigured and loaded with essential tools and settings to make interactivity with Oracle Cloud Infrastructure easy. Note that we’re using Cloud Shell only for convenience here. The tools can always be set up on developer workstations instead.

kubectl get nodes
  1. On the details page for your cluster, click Access Cluster.
  2. Choose Cloud Shell Access (the default).
  3. Click Launch Cloud Shell.
  4. To verify access to the cluster, run the following command:

The command should return a list of nodes in the cluster that you created and some information about them. For example:

NAME        STATUS   ROLES   AGE    VERSION   Ready    node    124d   v1.14.8   Ready    node    124d   v1.14.8

Deploy the application and verify the deployment

Now that you have a cluster and can interact with it, the next step is to build your application and deploy it to the cluster. The following steps outline the process of deploying this application:

  1. Get the application source code
  2. Prepare the cluster
  3. Deploy the application components
  4. Verify the deployment

Get the application source

Clone the code repository for the application. The Git source control tool is built in to Cloud Shell, and you can run the following command to get the source code:

git clone \ \

Then, change the directory. This is necessary because the following steps use file locations relative to the root of the source code.

cd mushop

Prepare the cluster

The application consists of two sets of components:

  • The microservices that make up the application
  • Supporting and optional components, such as Grafana dashboards and ingress controllers (Nginx)

We separate them in Kubernetes by using namespaces, a resource that can route traffic to multiple applications without each application having to create its own load balancer.

To prepare the cluster for the application, run the following commands:

kubectl create namespace mushop
kubectl create namespace mushop-utilities
kubectl config set-context \
  --current --namespace=mushop
helm dependency update deploy/complete/helm-chart/setup

Deploy the application components

Helm manages the application deployment as a set of Helm charts, which lets you manage the various individual services and their lifecycles easily.

Install the Helm charts for the application as follows:

helm install mushop-utils deploy/complete/helm-chart/setup \
  --namespace mushop-utilities
helm install mushop \
deploy/complete/helm-chart/mushop \
-f deploy/complete/helm-chart/mushop/values-mock.yaml

Verify the deployment

Now that the application is deployed, you should be able to access it from anywhere. The application manifest—the description of the application for Kubernetes—includes an ingress controller, a resource in Kubernetes that can route traffic to multiple applications. It has already set up an Oracle Cloud Infrastructure load balancer for you and has wired the routes for the MuShop application that you deployed.

To access the application, use the public IP address of the load balancer that was created. To find this, use the following command:

kubectl get svc -n mushop-utilities | grep ingress-controller

The second IP address in the output is the external public IP address where the application is available.

The application is fully functional, and navigating to the IP address by using your browser should display the home page for the application, as shown in the following image.

MuShop home page

Figure 2: MuShop home page

Make a change to the application

Now that the application is deployed, you can make a change to it and deploy the change. Here’s the process:

  1. Make a code change
  2. Create a Docker image with the updated application
  3. Push your local image
  4. Redeploy the application
  5. Verify the application

Make a code change

This application’s home page has a promotional banner, and you can change it quickly to see the effect.

  1. Go to the storefront source code folder.
    cd src/storefront/src/templates/data/
  2. Open the _data.pug file using your favorite editor.
  3. Go to the var promo section.
  4. Change the title Food! to OCI is Awesome!, and save the file. The following screenshot shows this change.

MuShop code sample

Figure 3: Storefront service code change

Create a Docker image with the updated application

Rebuild the application with a new beta flag.

docker build --build-arg version=2.0.1-beta -t mushop/storefront ~/mushop/src/storefront

Push your local image

Now that you have an updated image for the application that contains changes, you can push this image to Oracle Cloud Infrastructure Registry (OCIR), Oracle's enterprise-class private Docker registry.

To push a container image to a Registry repository, you first need to generate a user auth token. Use the following steps to generate a token.

  1. From the main menu in the Console, select Identity, and then select Users.
  2. Click the name of the user.
  3. Under Resources, click Auth Tokens.
  4. Click Generate Token.
  5. Enter a description and click Generate Token.
  6. Click the Copy link to copy the token, and save it somewhere. You need it to log in to Registry in the next section.

Now you can log in to Registry and push the image:

1. Log in to Registry:

docker login <region-key>

2. When prompted, enter your login name (email address) and password (auth token):

**Username**: <tenancy-name>/<user-name>
**Password**: <auth-token>

3. Tag the image with the path to the repository:

docker tag mushop/storefront <region-key><tenancy-name>/<repository-name>/mushop-storefront:2.0.1

docker push <region-key><tenancy-name>/<repository-name>/mushop-storefront:2.0.1

You need to change this repository to public so that you can pull this image during redeployment without adding imagepullsecrets in the Kubernetes YAML.

4. From the main menu in the Console, select Developer Services, and then select Container Registry.

5. Click the repository, and from the Actions menu, select Change to Public. To reconfigure the application to use the new image, you update the Helm chart that specifies which version of the application to use for your deployments.

6. Edit the deploy/complete/helm-chart/mushop/values-mock.yaml configuration file, and add the following text:

    tag: 2.0.1

Redeploy the application

With the values configured, deploy the application:

helm upgrade --install mushop \
deploy/complete/helm-chart/mushop \
-f deploy/complete/helm-chart/mushop/values-mock.yaml

To watch the progress and readiness of the deployment, run the following command:

kubectl get pod --watch

Verify the application

Refresh the MuShop application web page to see the change. A new promotional banner of “OCI is Awesome!” is displayed, as shown in the following screenshot.

Figure 4. Updated MuShop home page

Figure 4: Updated MuShop home page

Watch the video version of this tutorial (8:37)

Try Oracle Cloud Free Tier