You will have to use the module-level include
directive to specify which files belong to each module. You will also have to provide the path to the Dockerfile with the dockerfile
directive.
If the module only has a Dockerfile but no other files, say because it's a 3rd party image, you should set include: []
.
See this section of our docs for more.
Yes.
You can use the disabled
field to disable modules, services, tests, and tasks.
Both, actually.
When building: If the image
field is specified and Garden can't find a Dockerfile for the module, Garden will use that image when deploying the module. If there is a Dockerfile, Garden will build the image from it, regardless of whether or not the image
field is specified.
When publishing: If the image
field is specified and the module has a Dockerfile, Garden will build the image from the Dockerfile and publish it to the URL specified in the image
field. If there's no Dockerfile, the publish
command will fail.
We aim to change to this behavior and make it more user-friendly with our next major release.
Read all about it in this section of our docs.
We recommend using the Terraform module for cloud services that are shared by your team.
You can also deploy kubernetes
and helm
modules to their own namespaces.
You can use the copy directive of the build.dependencies[]
field for that. See e.g. this example project.
Alternatively you can hoist your garden.yml
file so that it is at the same level or parent to all relevant build context and use the include
field.
See this GitHub issue for more discussion on the two approaches.
Use the targetImage
field.
See this example project.
No, only modules can be build dependencies and runtime outputs come from tasks, tests, and services.
Set the log-level to debug
or higher. For example:
garden build --log-level debug
No. If you have multiple modules that use the same Dockerfile, you should instead have a single base image and then let each module have its own Dockerfile that's built on the base image. See the base image example project for an example of this.
See this example project.
Use the module-level extraFlags
field.
You can use the dockerfile
field. For example:
dockerfile: "${environment.name == 'prod' ? Dockerfile.prod : Dockerfile.dev}"
See also the base image example project for an example of this.
Not currently. Besides, multiple Docker daemons would not be able to share image layer caches.
You can, however, run multiple Kaniko pods in parallel. In some scenarios, that may scale better.
Please do not delete the garden-system
namespace directly, because Kubernetes may fail to remove persistent volumes. Instead, use this command:
garden plugins kubernetes uninstall-garden-services --env <env-name>
It removes all cluster-wide Garden services.
See this section of our docs.
See this section of our docs.
Use this command:
garden plugins kubernetes cleanup-cluster-registry --env <env-name>
It's on our roadmap to automate this.
We've been pondering this, but there are a lot of variants to consider. The key issue is really that the notion of "first time" is kind of undefined as things stand.
So what we generally do is to make sure tasks are idempotent and exit early if they shouldn't run again. But that means the process still needs to be started, which is of course slower than not doing it at all.
It is, which is why we recommend that tasks are written to be idempotent. Tasks by nature don’t really have a status check, unlike services.
This is intentional, we don't re-run tasks on file watch events. We debated this behavior quite a bit and ultimately opted not to run task dependencies on every watch event.
The task result is likely cached. Garden won't run tasks with cached results unless cacheResult: false
is set on the task definition.
You can also run it manually with:
garden run task <task-name>
This will run the task even if the result is cached.
Garden stores the task results as a ConfigMap under the <project-name>--metadata
namespace. You can delete them manually with this command:
kubectl delete -n <project-name>--metadata $(kubectl get configmap -n <project-name>--metadata -o name | grep task-result)
You can also run it manually with:
garden run task <task-name>
This will run the task even if the result is cached.
The garden test
command can run all your tests, or a subset of your tests, and has a --watch
flag. It won't re-run tests that are cached unless the --force
flag is set and it won't print the output unless the test fails. See here for the synopsis and examples.
The garden run test
command runs a single test in interactive mode regardless of whether or not it's cached. Interactive mode means that the output is streamed to the screen immediately and you can interact with it if applicable.
Note that due to a known limitation, Garden can't copy artifacts for tests in interactive mode. You can disable it by setting --interactive false
. See here for the full synopsis.
We plan on making --interactive=false
the default with our next major release.
See this section of our docs.
You'll need to use the kubernetes
or helm
module types for that. Here's the official Kubernetes guide for mounting secrets as files.
No, Kubernetes secrets can only be used at runtime, by referencing them in the environment
field of tasks
, services
and tests
. See the secrets section of our docs for more.
Also note that secrets as buildArgs
are considered a bad practice and a security risk.
No, secrets have to be in the same namespace as the project. This is how Kubernetes secrets are designed, see here for reference.
See this section of our docs.
You can generate the files via a task, store them as artifacts, and copy them from the local artifacts directory. Here's an example of this.
You can also use the persistentvolumeclaim
module type to store data and share it across modules. See this section of our docs for more.
You can set annotations on ingresses under the services[].ingresses[]
field.
Garden interfaces with your cluster via kubectl
and by using the Kubernetes APIs directly and should therefore work with all Kubernetes clusters that implement these. Garden is committed to supporting the latest six stable versions of Kubernetes.
No, you have to use the kubernetes
module type for that.
To Garden, a single Helm chart is a single "unit of deployment", which echoes the Garden notion of "service".
Therefore, a Helm chart with multiple deployments will only show up as a single service in Garden. You can, of course, deploy it with Garden, but it doesn't map as naturally to Garden services. This means that service-level functionality such as hot-reloading and getting service logs won't work as expected.
That said, a single Helm module can have multiple container modules as build dependencies and refer to the resulting images. So it should work just fine, but you'll have a coarser granularity when it comes to deploying them.
Unfortunately it's currently not feasible to support hot reloading for OpenFaaS, since it would require quite a lot of upstream work in OpenFaaS itself.
We're exploring how we can release it incrementally. Please let us know if this is something you're interested in.
The components installed when using the remote building functionality are discussed in the In-cluster building docs.
Garden also optionally installs Nginx. The local-kubernetes
provider defaults to installing Nginx, but the (remote) kubernetes
provider does not install it by default.
Furthermore, the openfaas
provider installs some components necessary for OpenFaas to work.
Of course, we use Garden to install these components, and you’ll find the Garden modules for them in in our source code under kubernetes/system
and openfaas/system
.
The *.local.app.garden
domain resolves to 127.0.0.1 via our DNS provider for convenience. If you want to use a different hostname for local development, you’ll have to add the corresponding entry to your hosts file.
No, it doesn't. See this question above for accessing files that are generated at runtime.
Garden is currently in use by many teams. We don’t have a set date or plan to label it as 1.0, but we don't expect to do it anytime soon. For comparison, very widely used tools like Terraform are still not at 1.0.
We have a team of people working on it full-time, and we make it a priority to address all non-trivial bugs. We’re also happy to help out and answer questions via our community Slack.
Garden is not currently designed to work in air-gapped environments This would require a fair amount of workarounds, unfortunately.