Migrating from Docker Compose to Garden
If you already have an application built using Docker Compose and want to migrate it to Garden, you can do this by adding the correct
*.garden.ymlfiles. In this guide, we'll walk through an example of converting a simple Docker Compose project to Garden. You can follow along with the example, or substitute your own Docker Compose project where relevant.
To follow along, you should have:
- A local Kubernetes cluster running inside Docker Desktop.
- A project that currently uses Docker Compose (or follow along using the provided example).
The frontend and backend modules each have their own Dockerfile, and there is a top-level
docker-compose.ymlfile to tie them together and to add MongoDB.
This application is based on the one at https://github.com/docker/awesome-compose/tree/master/react-express-mongodb. We've added four
*.garden.ymlfiles, which we'll walk through now in detail.
In the root of the directory, we've added
project.garden.ymlwith the following contents:
- name: default
- name: local-kubernetes
This is a
Projectlevel file. We call it
compose2gardenin our example, but you can use your own name. We configure a single environment and specify the hostname where we can visit the running application. Finally, we configure
local-kubernetes(a Kubernetes cluster running in Docker Desktop) as our provider.
For our backend module, we've added another Garden configuration file with the following contents:
description: The backend server.
- name: backend
- source: ./
- name: http
- path: /
This one is a
Moduleinstead of a
devMode, we set up syncing from the root folder to our built
appfolder so we can see code changes live when in developer mode. Under
ports, we specify the same port as in our Docker Compose file (3000). We set up a health check for the the
/apiroute, as that is what this module serves, and an ingress on a subdomain. In our case, this will let us access our backend service on
compose2garden.local.app.garden. Finally, we specify the dependency on the
mongomodule, which we will define in a bit.
For the frontend, we create another Garden module with the following contents:
description: The frontend server and UI components.
- name: frontend
- source: ./src
- name: http
- path: /
This is similar to the backend module, but we specify the backend as a dependency, which makes the database (
mongo) an indirect dependency.
Here we've created a
mongofolder, as it did not exist as an explicit module in our original Docker Compose project. The folder contains only the Garden configuration file, which contains:
description: Mongodb for storing todo items
- name: mongo
- name: data
- name: db
This specifies the same volume and port that we previously specified in Docker Compose.
With the four config files added, we can test our service on Garden. We've moved from running on Docker to running on a local Kuberenetes cluster now, so make sure your Docker Desktop is configured accordingly.
in the project folder. Garden will start up locally. You should see output in your terminal showing that this worked successfully.
Garden Dev terminal
If you visit the URL, you'll see the Garden dashboard, where you'll see the status of the three individual modules.
If you click on "Stack Graph", you'll see the dependency graph that Garden calculated. Building
frontendcan each be done independently, but deploying the frontend requires the backend to be deployed first, which in turn relies on
Garden Stack Graph
To build and deploy your project, terminate the
garden devprocess and run
garden deploy. Once this has completed, you'll have the example "To Do" application running on your local Kubernetes cluster.