> For the complete documentation index, see [llms.txt](https://tkssharma-devops.gitbook.io/devops-training/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tkssharma-devops.gitbook.io/devops-training/docker/docker-compose/docker-compose-demo.md).
# Docker Compose Demo
### How To Dockerize Node JS application with Mysql
I’ll be demonstrating the ease of ‘dockerizing’ an application with a full stack JavaScript application. This is a MERN application, except replace the MongoDB with a MySQL database.
Here’s a high level look at the file structure of this particular application. Since I’m demonstrating with a relatively small user registration app, I’m keeping the server and client in the same repo, but it would be very easy to break them up into multiple separate projects and knit them together with the help of `docker-compose.yml`s.
Side note: If these were to be two (or more) separate services, I would need to keep a `docker-compose.yml` in both repos so each could be spun up for local development. The service being developed would build a new image each time `docker-compose up` is invoked, and it would have access to the necessary other service’s Docker image stored in Docker Hub (or wherever you choose to store images) with the tag of the version I wanted in the `docker-compose.yml`. For production, there’d also be a third `docker-compose-prod.yml` which would only use images that were tested and approved. But that’s outside the scope of this article.
Back to the project file structure.
### App File Structure
```
root/
├── api/
├── client/
├── docker/
├── docker-compose.yml
├── Dockerfile
```
Obviously, there’s plenty of files contained within each one of these directories, but for simplicity’s sake I’m just showing the main file structure.
Even though both the `client` and `api` folder are contained within the same repo, I built them with micro services and modularity in mind. If one piece becomes a bottleneck and needs a second instance, or the app grows too large and needs to be split apart, it’s possible to do so without too much refactoring. To achieve this modularity, both my API and client applications have their own `package.json` files with the dependencies each app needs to run. The nice thing is, since this is currently one application and both apps are JavaScript, I can have one `Dockerfile` that works for both.
### The Dockerfile
Here’s what the `Dockerfile` looks like:
```
// download a base version of node from Docker Hub
FROM node:9// create the working directory for the application called /app that will be the root
WORKDIR /app// npm install the dependencies and run the start script from each package.json
CMD ls -ltr && npm install && npm start
```
That’s all there is to it for this Dockerfile: just those three commands. The `docker-compose.yml` has a little bit more to it, but it’s still easy to follow, when it’s broken down.
### The Docker-Compose.yml
```
version: '3.1'
services:
client:
build: .
volumes:
- "./client:/app"
ports:
- "3031:3000"
depends_on:
- api
api:
build: .
volumes:
- "./api:/app"
ports:
- "3003:3000"
depends_on:
- db
db:
image: mysql:5.7
restart: always
environment:
MYSQL_ROOT_PASSWORD: example
MYSQL_DATABASE: users
MYSQL_USER: test
MYSQL_PASSWORD: test1234
ports:
- "3307:3306"
volumes:
- ./docker/data/db:/var/lib/mysql
```
I would like to note there’s a newer version of MySQL available on Docker Hub, but I couldn’t get it to work properly with Docker Compose, so I would recommend going with the mysql:5.7 version until further notice.
