3. Add Actions
Last updated
Was this helpful?
Last updated
Was this helpful?
With our Kubernetes environment set up, we can start adding Garden actions for building and deploying our project.
First, log in to the dashboard by running:
Then start the interactive dev console with:
You can follow the link to open the dashboard but there won't be much there yet since we haven't added actions to our project.
Next, let's add Garden actions for deploying the database.
First, create a garden.yml
config file in the ./db
directory.
We'll use actions of kind Deploy
and Run
to deploy and seed the database. Each action also has a type which determines how it's executed and depends on the plugins that we're using.
Since this is for a development environment we can deploy the database directly to our Kubernetes cluster. Let's use a Postgres Helm chart and add a Deploy action of type helm
.
You'll find all the available types under the page in the Kubernetes Plugins section.
Now add the following to ./db/garden.yml
:
Note also the resource
field which tells Garden what resource to execute the command in.
Next, let's add actions for the API.
This time we'll use actions of kind Build
and Deploy
to (unsurprisingly) build and deploy the API.
First, create a garden.yml
config file in the ./api
directory.
Then add the following Build action to the file:
Now, try building the API by running the following from the interactive dev console:
Try running the build
command one more time. Notice how Garden checks the status of the action and tells you that the API is already built?
This is how you can share build caches with your entire team when using Garden against your own remote Kubernetes environment. Once a given part of your system has been built, everyone else on the teamโand your CI pipelinesโcan re-use it and save massive amounts of time otherwise spent waiting for builds.
Next, we'll add an action for deploying the API.
Since we already have Kubernetes manifests for the API in the ./manifests
directory we'll use the kubernetes
action type and add the following below the Build action in ./api/garden.yml
:
Note the patchResources
field. When Garden builds the API it attaches a version to the image based on the version of that action (which is based on the source code and action configuration). To ensure we deploy the correct version of the action we overwrite the image
field in the corresponding manifest by applying the patch
we specify under the patchResources
field.
There are a few ways to overwrite manifest values with Garden but this is the recommended approach since it allows you to re-use existing manifests without making any changes to them. You can learn more about the different approaches here.
Next, lets deploy the API.
You should see all your actions and their dependencies. Click the button on the API deploy action to "execute" the action and deploy the API. Notice how Garden will first install the database, then seed it, and then deploy the API.
Notice also how Garden sees that the API has already been built (when we ran the build
command above) and can get straight to deploying it once the upstream dependencies are ready.
The actions for the web service will be very similar.
First, create a garden.yml
file in the web
directory and then add the following:
Now try deploying the entire project by running the following from the interactive dev console:
Here we're using the kubernetes-exec
action type to seed the database by executing a command inside the running Pod. This is a good choice for development but another common pattern is to run separate Pods for these kind of one-off operations, e.g. via a container
Run action. You can learn about the different Run actions .
For higher environments we recommend using our or plugins to deploy a proper managed database instance.
You can view the results and the logs in the .
By default, Garden will look for a Dockerfile next to the Garden config file but you can configure this. See and .
This time, try opening the Live page in the and selecting the Graph view.
If you have a lot of actions with similar config, you can create to avoid the boilerplate.
Garden will print links to your services in the dev console. You'll also find them in the .