This is an example project using Node.js with the Express getting started generator. With the OCI DevOps service and this project, you'll be able to build, test and deploy this application to Oracle Container Engine for Kubernetes (OKE) via Helm Charts.
In this example, you'll build a container image of this Node Express Getting Started App, and deploy your built container to the OCI Container Registry, then deploy the getting started app to Oracle Container Engine for Kubernetes (OKE) all using the OCI DevOps service!
Let's go!
The first step to get started is to download the repository to your local workspace
git clone http://github.com/oracle-devrel/helm-oci-devops-node-service
cd helm-oci-devops-node-service
Open a terminal and test out the simple Express example - a web app that returns a "Welcome to Express" page
- Install Node 12 and NPM: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm
- Build the app:
npm install
- Run tests:
npm test
- Run the app:
npm start
- Verify the app locally, open your browser to http://localhost:3000/ or whatever port you set, if you've changed the local port
You can locally build a container image using docker (or your favorite container image builder), to verify that you can run the app within a container
docker build --pull --rm -t node-express-getting-started -f DOCKERFILE .
Verify that your image was built, with docker images
Next run your local container and confirm you can access the app running in the container
docker run --rm -d -p 3000:3000 --name node-express-getting-started node-express-getting-started:latest
And open your browser to http://localhost:3000/
Now that you've seen you can locally build and test this app, let's build our CI/CD pipeline in OCI DevOps
- Create a DevOps project, or use an existing project
- Create a Code Repository in your DevOps project
- Add the new Code Repository as a remote to your local git repo
git remote add devops ssh://devops.scmservice.us-ashburn-1.oci.oraclecloud.com/namespaces/MY-TENANCY/projects/MY-PROJECT/repositories/MY-REPO
- View the Getting Started Guide to connect to your Code Repository via https or ssh
Create a new Build Pipeline to build, test and deliver artifacts from a recent commit
In your Build Pipeline, first add a Managed Build stage
- The Build Spec File Path is the relative location in your repo of the build_spec.yaml . Leave the default, for this example
- For the Primary Code Repository choose your Code Repository you created above
- The Name of your Primary Code Repository is used in the build_spec.yaml. In this example, you will need to use the name
node_express
for the build_spec.yaml instructions to acess this source code - Select the
main
branch
- The Name of your Primary Code Repository is used in the build_spec.yaml. In this example, you will need to use the name
Create a Container Registry repository for the node-express-getting-started
container image built in the Managed Build stage.
- You can name the repo:
node-service
. So if you create the repository in the Ashburn region, the path is iad.ocir.io/TENANCY-NAMESPACE/node-express-getting-started - Set the repostiory access to public so that you can pull the container image without authorization, from OKE. Under "Actions", choose
Change to public
.
Create a Container Registry repository for the helm-repo
container image built in the Managed Build stage.
- You can name the repo:
helm-repo
. So if you create the repository in the Ashburn region, the path is iad.ocir.io/TENANCY-NAMESPACE/node-service-helm-repo - Set the repostiory access to public so that you can pull the container image without authorization, from OKE. Under "Actions", choose
Change to public
.
The version of the container image that will be delivered to the OCI repository is defined by a parameter in the Artifact URI that matches a Build Spec exported variable or Build Pipeline parameter name.
Create a DevOps Artifact to point to the Container Registry repository location you just created above. Enter the information for the Artifact location:
- Name: node-express-getting-started container
- Type: Container image repository
- Path:
iad.ocir.io/TENANCY-NAMESPACE/node-service
- Replace parameters: Yes
Next, you'll set the container image tag to use the the Managed Build stage exportedVariables:
name for the version of the container image to deliver in a run of a build pipeline. In the build_spec.yaml for this project, the variable name is: BUILDRUN_HASH
exportedVariables:
- BUILDRUN_HASH
Edit the DevOps Artifact path to add the tag value as a parameter name.
- Path:
iad.ocir.io/TENANCY-NAMESPACE/node-service:${BUILDRUN_HASH}
Now create DevOps Artifact for helm-repo
too.
- Name:
node-service-helm
- Type:
Helm Chart
- Helm Chart URL:
oci://iad.ocir.io/TENANCY-NAMESPACE/helm-repo/node-service
- Version:
0.1.0-${BUILDRUN_HASH}
Default values.yaml
is found in /helm
folder. But values.yaml
can be overridden by creating Artifact in DevOps Project.
- Goto
Artifacts
in your DevOps Project. - Click on
Add Artifact
and enter Name asvalues.yaml
, Type asGeneral artifact
, Artifact Source asInline
, value as content give below.
replicaCount: 3
service:
type: LoadBalancer
port: 80
image:
repository: iad.ocir.io/TENANCY-NAMESPACE/node-service
pullPolicy: IfNotPresent
# Overrides the image tag whose default is the chart appVersion.
tag: ${BUILDRUN_HASH}
- Save the artifact.
Note:
- This values.yaml changes replicaCount to
3
from1
and makes the service asLoadBalancer
for public IP Address to get assigned. - Replace
TENANCY-NAMESPACE
with your valid tenancy name.
Let's add a Deliver Artifacts stage to your Build Pipeline to deliver the node-service
container to an OCI repository.
The Deliver Artifacts stage maps the ouput Artifacts from the Managed Build stage with the version to deliver to a DevOps Artifact resource, and then to the OCI repository.
Add a Deliver Artifacts stage to your Build Pipeline after the Managed Build stage. To configure this stage:
- In your Deliver Artifacts stage, choose
Select Artifact
- From the list of artifacts select the
node-express-getting-started container
artifact that you created above - In the next section, you'll assign the container image outputArtifact from the
build_spec.yaml
to the DevOps project artifact. For the "Build config/result Artifact name" enter:output01
build_spec.yaml
takes care of running build and pushing helm charts to the OCIR repository. For publishing helm charts to OCIR, the credentials and OCIR path are sent as parameters. Under Parameters
tab create below parameters with appropriate valid values.
Parameter | Description | Sample |
---|---|---|
USER_AUTH_TOKEN | Auth token of the user who has access to OCIR. Refer documentation to create token. | |
HELM_REPO_USER | User name to publish helm package to OCIR | <TENANCY_NAME>/<USER_NAME> |
HELM_REPO_URL | OCIR helm repository URL | oci://iad.ocir.io/<TENANCY_NAME>/node-service-helm-repo |
HELM_REPO | OCIR domain name | iad.ocir.io |
Use the Manual Run button to start a Build Run
Manual Run will use the latest commit to your Primary Code Repository, if you want to specify a specific commit, you can optionally make that choice for the Primary Code Repository in the dropdown and selection below the Parameters section.
To automatically start your Build Pipeline from a commit to your Code Repository, navigate to your Project and create a Trigger.
A Trigger is the resource to filter the events from your Code Repository and on a matching event will start the run of a Build Pipeline.
Test out your Trigger by editing a file in this repo and pushing a change to your DevOps code repository.
For CI + CD: continous integration with a Build Pipeline and continuous deployment with a Deployment Pipeline, first create the Deployment Pipeline to deploy this example web application service to your OKE cluster. To review Deployment Pipelines, see the example Reference Architecture, and docs. You'll need to setup the policies to enable deployments, as well.
Because the K8s manifest doesn't change each build, we're just going to create a single version of the K8s manifest by hand (or via API/CLI), in the Artifact Registry.
- Create an Enivornment to point to your OKE cluster destination for this example. You will already need to have an OKE cluster created, or go through the Reference Architecture automated setup.
You've created the references to your OKE cluster and manifest to deploy, now create your Deployment Pipeline
- Create a new Deployment Pipeline
- Add your first stage - choose the type to deploy helm to OKE:
Install helm chart to Kubernetes Cluster
- Add stage name
- Choose the Environment that you created above
- For Select Artifact, select the Helm Chart DevOps artifact that points to
node-service-helm
- For Select values artifacts, select values.yaml DevOps artifact that points to
values.yaml
- Add
To run this pipeline on its own, you can add a parameter for BUILDRUN_HASH
or, trigger it from the Build Pipeline which will forward the build_spec.yaml
exported variables to the Deployment Pipeline.
Once you've created your Deployment Pipeline, you can add a Trigger Deployment stage as the last step of your Build Pipeline.
After the latest version of the container image is delivered to the Container Registry via the Deliver Artifacts stage, we can start a deployment to an OKE cluster
- Add stage to your Build Pipeline
- Choose a Trigger Deployment stage type
- Choose
Select Deployment Pipeline
to choose the Deployment Pipeline that you created above.
From the Deployment Pipeline you selected, you can confirm the parameters of that pipeline in the Deployment Pipeline details.
Fork this repo from Github and make changes if you want to play around with the sample app, the OCI DevOps build configuration, and the k8s manifest.