When you've finished the development work for your Appsody project, you will have a containerized application that's ready to deploy to a suitable runtime infrastructure such as a cloud platform that hosts a Kubernetes cluster.
The Appsody CLI provides the appsody deploy command to build and deploy a Docker image directly to a Kubernetes cluster that you are using for testing or staging.
You can delegate the build and deployment steps to an external pipeline, such as a Tekton pipeline that consumes the source code of your Appsody project after you push it to a GitHub repository. Within the pipeline, you can run appsody build, which builds the application image and generates a deployment manifest. You can use the manifest to deploy your application to a Kubernetes environment where the Appsody operator is installed.
These deployment options are covered in more detail in the following sections.
There are many options to deploy your Appsody applications to a Kubernetes cluster. The best approach depends on the specific scenario:
appsody deployis your best bet
appsody deploy command provides a way for you to deploy your application directly to a Kubernetes cluster. The stack contains a deployment manifest that can be consumed by the Appsody operator.
appsody deploy will install the operator, if necessary, and deploy your application to the cluster using that deployment manifest.
If you want to deploy your application without rebuilding the application image, or modifying the deployment manifest, you can run
appsody deploy --no-build
Kubernetes operators offer a powerful way to provide full lifecycle maintenance of a wide range of resources on Kubernetes clusters. In particular, they can install, upgrade, remove, and monitor application deployments. The recently published Appsody operator automates the installation and maintenance of a special type of Custom Resource Definitions (CRDs), called AppsodyApplication.
The Appsody stacks that are currently available include a template of such a CRD manifest. When you run
appsody deploy on a project created from one of the stacks enabled with those manifests, the CLI customizes the manifest with information that is specific to the deployment (such as namespace and project name), and submits the manifest to the Appsody operator on the Kubernetes cluster.
In fact, if your cluster does not already provide an operator,
appsody deploy will install one for you. You can also use the Appsody CLI to install an instance of the Appsody operator, without installing any applications. This can be achieved by running the
appsody operator install command.
To find out more about the Appsody operator, see here.
You can deploy your application as a Knative service on your target Kubernetes cluster by using the
--knative flag with the
appsody build or
appsody deploy commands. This action sets the flag
createKnativeService in the deployment manifest to
For your app to work as a Knative service, the following pre-requisites apply:
kubectlCLI to point to your Kubernetes cluster.
appsody deploy --knative command completes successfully, the Knative Service is operable at the URL specified in the command output.
If you have installed a Kubernetes cluster on your development workstation and want to use your local Docker image cache instead of pushing the image to Docker Hub, make sure you set up your Kubernetes cluster to consume images from the local Docker cache.
To deploy your Appsody project locally, run:
This command completes the following actions:
appsody buildand creates a deployment Docker image and a manifest file named
app-deploy.yaml, as described in the previous section.
--knativeflag, or if Knative is the only deployment option for your stack, the command tags the image with the special prefix
dev.local, making it accessible to your Kubernetes cluster (assuming you followed these directions)
app-deploy.yaml, is used to issue a
kubectl apply -fcommand against the target Kubernetes cluster so that the application can be deployed by the Appsody Operator.
If your cluster is configured to pull images from Docker Hub, use the following command to deploy your application:
appsody deploy -t <mynamespace/myrepository[:tag]> --push --namespace mynamespace [--knative]
The command completes the following actions:
appsody buildand creates a deployment image, as described in the previous section.
-t mynamespace/myrepository[:tag]flag tags the image.
--pushflag tells the Appsody CLI to push the image to Docker Hub.
app-deploy.yamlin the project directory, if one doesn’t exist already. If a deployment manifest file exists, this command updates the following entries within it: application image, labels, and annotations. In addition, the
createKnativeServiceentry is set to true if you specified the
kubectl apply -fcommand against the target Kubernetes cluster. The Yaml file is set to use the Appsody operator.
--namespace mynamespaceoption provisions the deployment under the specified Kubernetes namespace within your cluster.
If you don't specify
--push, the image is available only on your local Docker registry and the target Kubernetes cluster must be configured to have access to your local Docker registry.
If your cluster is configured to pull images from a custom registry, use the following command to deploy your application:
appsody deploy -t <mynamespace/myrepository[:tag]> --push-url <registry-url:PORT>
If you are specifying different push and pull registries, for example, you might want to push to an external registry and pull from an internal registry, use the following command:
appsody deploy -t <mynamespace/myrepository[:tag]> --push-url <external-registry-url:PORT> --pull-url <internal-registry-url:PORT>
Note: The pull registry url gets injected into the deployment manifest for Kubernetes to pull the correct image.
If you are running multiple Appsody projects on your workstation, you can use
appsody deploy and
appsody operator commands to get them deployed to a Kubernetes cluster. However, make sure that you run these commands one at a time, because those commands create temporary files that might lead to conflicts if created concurrently.
Some users have noticed that their code changes do not seem to be published to the target Kubernetes cluster after an initial deployment of the Appsody project through
The sequence of actions that leads to this behavior is as follows:
appsody deployto publish it to your test Kubernetes cluster.
This behavior can be explained by the fact that - if you simply issue
appsody deploy without explicitly tagging the image - you end up with a deployment manifest (the
app-deploy.yaml file) that is identical to the one that was used to deploy the application the first time. Therefore, Kubernetes will detect no differences in the deployment yaml, and will do nothing to update your app.
To ensure that the latest version of your app is pushed to the cluster, use the -t flag to add a unique tag every time you redeploy your app. Kubernetes then detects a change in the deployment manifest, and pushes your app to the cluster again. For example: appsody deploy -t dev.local/my-image:0.x, where x is a number that you increment every time you redeploy.
This deployment option is under development
Most likely, the deployment of apps created with the Appsody CLI is going to occur through the invocation of a CI/CD build pipeline.
As a developer, you develop your app using the Appsody CLI, and when you are ready to deploy, you push your code to a repo or create a pull request on GitHub.
This example shows you how to use Tekton pipelines to deploy your app to a Kubernetes cluster. More details on running the Tekton pipeline example for Appsody can be found in the repo readme file. The example uses a customized Buildah image with the Appsody CLI installed. For more information on using Appsody with Buildah, see the FAQ.