The application code is stored in source control, along with its Dockerfile and Knative service definition. If your app doesn't have a Knative service definition, the toolchain automatically generates one during deployment. The target cluster is configured during toolchain setup by using an IBM Cloud API key and cluster name. You can update them at any time by altering the Delivery Pipeline configuration. Any code changes detected in the Git repo are automatically built, validated, and deployed into the Kubernetes cluster.
You can continuously deliver a secure Knative Service container app to a Kubernetes Cluster. Learn how to create a "Hello World" application that uses Docker, Node.js, and a DevOps toolchain. The app comes preconfigured for continuous delivery with the following features:
- Vulnerability Advisor
- Source control
- Issue tracking
- Online editing
- Knative deployment to the IBM Kubernetes Service
- Depending on your IBM Cloud account type, access to certain resources might be limited or constrained. Depending on your plan limits, certain capabilities required by this toolchain might not be available.
- Install the IBM Cloud CLI, the IBM Cloud Kubernetes Service plug-in, and the Kubernetes CLI.
- Create a standard Kubernetes cluster with 3 worker nodes that each have 4 cores and 16 GB memory (b3c.4x16) or more. For more information, see Creating a standard classic cluster in the console. Ensure that you note the total monthly cost before you create the cluster.
- Install the Istio add-on.
- Install the Knative add-on.
- To get started, click Create toolchain:
- You can use the default settings, or make changes as needed.
- Under Tool Integrations, select Delivery Pipeline.
- Enter your IBM Cloud API key, or generate a new API key by clicking Create.
- Confirm the container registry region, container registry namespace, and cluster information.
- Click Create.
The following best practices are implemented automatically upon app creation:
- Sanity check the Dockerfile before image creation.
- Build a container image on every Git commit, setting a tag based on build number, time stamp, and commit ID for traceability.
- Use a private image registry to store the image, and automatically configure access permissions for target cluster deployment by using API tokens that can be revoked.
- Check the container image for security vulnerabilities.
- Insert the image tag into the deployment manifest automatically.
- Use an explicit namespace in a cluster to insulate each deployment, which makes it easy to clear by running
kubectl delete namespace.