Home > Article > Backend Development > From legacy to cloud serverless - Part 1
Note: This article was originally published on Nov 4, 2023 here. It has been republished here to reach a broader audience.
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 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 on GitHub if you haven't built your own.
Once you have your app built, let's get started!
Here is the structure of the application directory that we will containerize, followed by the Dockerfile.
. ├── app.py ├── LICENSE ├── README.md ├── requirements.txt ├── static │ └── style.css └── templates └── index.html
The 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.
# 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:
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.
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.
The WORKDIR instruction sets the working directory to /app, which is where the application code will be copied.
The COPY instruction copies the requirements.txt file to the container's /app directory.
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.
The ENV instruction adds the directory containing the flask command to the PATH environment variable. This is necessary to run the flask command later.
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.
The COPY instruction copies the application code (app.py), templates (templates/), and static files (static/) to the container's /app directory.
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.
The EXPOSE instruction exposes port 5000, which is the default port used by Flask.
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.
Here is the basic Docker Compose YAML file that we will use to streamline the process.
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):
Web アプリケーション (Web):
ボリューム:
要約すると、この Docker Compose ファイルは MongoDB データベースと Flask Web アプリケーションのデプロイメントを調整し、それらがシームレスに通信して連携できるようにします。
次に、Docker Compose ファイルのあるディレクトリに移動し、docker-compose up を実行して MongoDB と Flask Web アプリを起動します。 http://localhost:5000 でアプリにアクセスし、すべてが期待どおりに動作することを確認します。
停止するには、docker-compose down を使用します。
大丈夫ですか?次は、次の記事でワークフローを Kubernetes に移行します。
The above is the detailed content of From legacy to cloud serverless - Part 1. For more information, please follow other related articles on the PHP Chinese website!