Oracle Cloud Infrastructure has a free DevOps cloud service that includes build and deploy pipelines in addition to source code and artifact repositories. I have written about OCI DevOps Deployment Pipelines and its Build Pipelines in earlier articles. In this article, I will show you a deployment pipeline on OCI DevOps for a Function. The serverless functions service on OCI uses function definitions packaged as container images in OCI Container Registry. Deployment of a function consists of the steps shown below:
- Get access to the target environment — Deployment Pipelines work through a Service Principal — an OCI Dynamic Group that has access privileges inherited from OCI Security Policies. No credentials need to be included in Pipelines — the pipelines need to be in a group with sufficient privileges for the actions the pipeline performs
- Acquire the software artifact to be deployed — in this case a reference to a container image from the OCI Container Registry
- Get hold of the configuration values that need to be “injected” into the runtime — note that at present, OCI DevOps Deployment Pipeline unfortunately at present can not set function configuration values.
- Update the Function with (a reference to) the new container image. Note: at present the function that is deployed already needs to exist. It can be based on the scratch container image or some other fake image, but it needs to exist for the deployment pipeline to be defined and for it to succeed.
- Smoke test — verify the success of the deployment by checking the deployed function can be accessed in the expected way.
An OCI DevOps Deployment pipeline is part of a project. A project is the logical grouping of Pipelines (for build and deploy), code repositories, artifact repositories, triggers (to trigger a build pipeline from a code repository event), external connection (to integrate with external code repositories) and environment (that define a destination to deploy to. At project level we can also inspect history of pipelines, logging and metrics.
Here is the overview page for my project.
In order to be able to deploy the Function Tweet_Retriever in Application cloudnative_2021App in Compartment cloudnative-2021 I have created the following resources:
- an OCI DevOps Project
- an Artifact – the reference to in this case a specific Container Image in the OCI Container Image Registry, using the fully qualified path to the repository and the specific image version (note that I can use a parameter in the path that is resolved when the deployment pipeline using the artifact is executed
- an Environment – the reference to the Function I want to (re)deploy. The Environment in case of Function deployment is not the compartment or an application in an compartment (as I had expected) but currently the function itself that therefore needs to exist before it can be deployed through an OCI DevOps Deployment Pipeline. (note that the Function does not have to be useful – it can be based on he Scratch container image)
- a Deployment Pipeline with a Deployment Pipeline Stage of type Function Deployment that connects the artifact and the environment.
Let’s take a look at all of this in the OCI Console.
The project overview:
The Artifact definition:
Note the use of the ${imageVersion} parameter in the image path. This parameter needs to be substituted with an actual value before a real image can be retrieved.
The environment:
Again, the environment is not just the context into which the function is deployed – it is a reference to the function itself.
The Deployment Pipeline is now very straightforward – take an environment and an artifact, add if needed some parameters and create a Deployment Stage of the proper type for this combination.
The Parameter definitions go on the designated tab.
Rememember how the artifact was defined with the expression ${imageVersion} in the fully qualified image path. This parameter imageVersion will provide the value that is substituted in that path when the pipeline is executed.
The deployment pipeline can be started manually in various places. It can also be started from a Terraform plan, through the CLI or REST API, using the Jenkins plugin or automatically from a Build Pipeline. When the pipeline is started, values can be provided for the pipeline parameters (to override the default values):
Next, Start Manual Run. And the pipeline executes.
When successfully completed, the function will now be based on the indicated container image.
What the Deployment Pipeline cannot do (currently) is define the configuration settings for the function. To me that seems like an obvious thing it should be able to do, so I hope the product team at Oracle will soon add that capability. For now, what we can do for this or other extra capabilities is add another step to the deployment pipeline that will invoke a Function (not the one we have just deployed) that can do additional housekeeping tasks – such as defining the configuration settings or making a test call to the function that was just deployed as a smoke test.
Summary
The OCI DevOps Deployment Pipeline provide a structured approach to automated deployment of different types of artifacts on OCI. Deploying a function is one of the artifacts that the service currently supports. Creating and running such a function deployment pipeline is quite straightforward. Together with a build pipeline, this will help teams to perform software engineering tasks on OCI. The fact that OCI DevOps Deployment Pipelines are a free feature of Oracle Cloud Infrastructure is quite nice as well.
Resources
OCI Docs on DevOps: https://docs.oracle.com/en-us/iaas/Content/devops/using/home.htm
My article on OCI DevOps Deployment Pipelines
Announcement of OCI DevOps Cloud Service: https://blogs.oracle.com/cloud-infrastructure/post/simplify-your-software-deployments-with-the-oci-devops-service
Jenkins Plugin for OCI DevOps Deployment Pipelines: https://www.jenkins.io/doc/pipeline/steps/oracle-cloud-infrastructure-devops/
