# From legacy to cloud serverless


Welcome to the first article in a series that will walk you through the process of migrating a legacy app from on-premises to the cloud, with a focus on modernization, serverless platforms, and integrated DevOps practices.

In this article, we will focus on containerizing your app. However, if you're building an app from scratch, that's perfectly fine (in fact, it's even better). For this example, I'm using [this DigitalOcean guide](https://www.digitalocean.com/community/tutorials/how-to-use-mongodb-in-a-flask-application) to build a simple TODO app using Python (Flask) and MongoDB as the database. I've made some customizations to make it look better, but the main point is to build something that uses a NoSQL document-based database, as this will be required for the upcoming work.

You can clone the repository of the app [here](https://github.com/davWK/legacy-to-cloud-serverless) on GitHub if you haven't built your own.

Once you have your app built, let's get started!

# Dockerfile

Here is the structure of the application directory that we will containerize, followed by the Dockerfile.

```bash
.
├── app.py
├── LICENSE
├── README.md
├── requirements.txt
├── static
│   └── style.css
└── templates
    └── index.html
```

The [app.py](http://app.py) file is the main application file that contains the Flask app code. The requirements.txt file contains the list of Python dependencies required by the application. The static/ directory contains static files such as CSS, JavaScript, and images. The templates/ directory contains the HTML templates used by the Flask app.

```yaml
# Use a minimal base image
FROM python:3.9.7-slim-buster AS base

# Create a non-root user
RUN useradd -m -s /bin/bash flaskuser
USER flaskuser

# Set the working directory
WORKDIR /app

# Copy the requirements file and install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Add the directory containing the flask command to the PATH
ENV PATH="/home/flaskuser/.local/bin:${PATH}"

# Use a multi-stage build to minimize the size of the image
FROM base AS final

# Copy the app code
COPY app.py .
COPY templates templates/
COPY static static/

# Set environment variables
ENV FLASK_APP=app.py
ENV FLASK_ENV=production

# Expose the port
EXPOSE 5000

# Run the app
CMD ["flask", "run", "--host=0.0.0.0"]
```

Here's a walkthrough and breakdown of the Dockerfile:

1. The Dockerfile starts with a `FROM` instruction that specifies the base image to use. In this case, it's `python:3.9.7-slim-buster`, which is a minimal base image that includes Python 3.9.7 and some essential libraries.
    
2. The next instruction creates a non-root user named `flaskuser` using the `RUN` and `useradd` commands. This is a security best practice to avoid running the container as the root user.
    
3. The `WORKDIR` instruction sets the working directory to `/app`, which is where the application code will be copied.
    
4. The `COPY` instruction copies the `requirements.txt` file to the container's `/app` directory.
    
5. The `RUN` instruction installs the dependencies listed in `requirements.txt` using `pip`. The `--no-cache-dir` option is used to avoid caching the downloaded packages, which helps to keep the image size small.
    
6. The `ENV` instruction adds the directory containing the `flask` command to the `PATH` environment variable. This is necessary to run the `flask` command later.
    
7. The `FROM` instruction starts a new build stage using the `base` image defined earlier. This is a multi-stage build that helps to minimize the size of the final image.
    
8. The `COPY` instruction copies the application code ([`app.py`](http://app.py)), templates (`templates/`), and static files (`static/`) to the container's `/app` directory.
    
9. The `ENV` instruction sets the `FLASK_APP` and `FLASK_ENV` environment variables. `FLASK_APP` specifies the name of the main application file, and `FLASK_ENV` sets the environment to `production`.
    
10. The `EXPOSE` instruction exposes port `5000`, which is the default port used by Flask.
    
11. The `CMD` instruction specifies the command to run when the container starts. In this case, it runs the `flask run` command with the `--host=0.0.0.0` option to bind to all network interfaces.
    

With this Dockerfile, the application can be containerized and executed. However, it's important to note that our app requires a database to store the data created or generated while it's running. Of course, you could separately pull a MongoDB database image and run it independently. Then, make adjustments on both sides to establish communication between the two containers so that the app can successfully store data in the database. While this approach works, it may consume time and be a bit tedious. To streamline the process, we will instead move forward with Docker Compose. In Docker Compose, everything is declared in a YAML file, and by using the `docker-compose up` command, we can start and operate the different services seamlessly, saving time and effort.

# Streamlining Database Integration with Docker Compose

Here is the basic Docker Compose YAML file that we will use to streamline the process.

```yaml
version: '3.9'

services:
  db:
    image: mongo:4.4.14
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db

  web:
    build: .
    container_name: "myflaskapp"
    ports:
      - "5000:5000"
    environment:
      - MONGO_URI=mongodb://db:27017
    depends_on:
      - db

volumes:
  mongo-data:
```

This Docker Compose YAML file is configured to set up two services: a MongoDB database (`db`) and a web application (`web`). Here's a breakdown:

* **Version:** Specifies the version of the Docker Compose file format being used (`3.9` in this case).
    
* **Services:**
    
    * **Database (**`db`):
        
        * Uses the MongoDB version `4.4.14` image.
            
        * Maps the host port `27017` to the container port `27017`.
            
        * Utilizes a volume named `mongo-data` to persistently store MongoDB data.
            
    * **Web Application (**`web`):
        
        * Builds the Docker image from the current directory (`.`).
            
        * Sets the container name as "myflaskapp."
            
        * Maps the host port `5000` to the container port `5000`.
            
        * Defines an environment variable `MONGO_URI` with the value `mongodb://db:27017`, establishing a connection to the MongoDB service.
            
        * Specifies a dependency on the `db` service, ensuring that the database is started before the web service.
            
* **Volumes:**
    
    * Defines a volume named `mongo-data` for persisting MongoDB data.
        

In summary, this Docker Compose file orchestrates the deployment of a MongoDB database and a Flask web application, ensuring they can communicate and function together seamlessly.

Now navigate to the directory with the Docker Compose file and run `docker-compose up` to start MongoDB and a Flask web app. Access the app at `http://localhost:5000` to ensure everything works as expected.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1696780578097/bf79e8c0-f0c2-4f0e-b69e-faccc92f1aa8.png align="center")

To stop, use `docker-compose down`.

All good? Next up: migrating the workflow to Kubernetes in the next article.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1696780189965/eaa848eb-c48c-4e04-b5dc-b8f80d68bfcc.jpeg align="center")