[PYTHON] [Day 3] Study session to deploy from docker-compose to Kubernetes with minimal configuration

Overview

The contents of the third day of the study session of the title are described. Please see the following summary page for the contents of the whole day.

[Summary] Study session to deploy from docker-compose to Kubernetes with minimum configuration

What I did on the third day

--Creating a container image for testing --Incorporate tests into CI / CD pipelines

Contents of the third day

Creating a container image for testing

image.png

Create a container to run a simple test. Use python to send a request and determine the result. If the content returned to the request contains the character string puyopuyo, which explains the process in detail, it ends normally withsys.exit (0). On the contrary, if it is not included, sys.exit (1) will result in an abnormal termination. This leads to the later GitLab CI / CD.

import os
import requests
import sys

url = os.getenv('URL', 'http://localhost:3000')
check_str = os.getenv('CHECK_STR', 'Puyo Puyo')

try:
    r_get = requests.get(url)
    response = True if r_get.ok else r_get.reason
    print(r_get.text)
    if r_get.text.find(check_str) == -1:
        print(check_str + "It's not a problem! !!")
        sys.exit(1)
    else:
        print(check_str + "So it's okay.")
        sys.exit(0)
except requests.exceptions.RequestException as e:
    response = str(e)
    sys.exit(1)

Try the test with python only

This test can also be run on the local python. In the local python environment, requests must be ʻImport` in advance. You can run the test by following the steps below.

--Install Python -- pip install requests if there is no requests --Use docker-compose to ʻup ʻapp --Move to the top folder

Add test to docker-compose.yml

First, prepare Dockerfile to create a container. ʻAlpine does not include requests`, so I installed it.

■ Dockerfile

FROM python:3.6-alpine

WORKDIR /app

COPY ./*.py /app/

RUN pip install requests

CMD ["python", "test.py" ]

Based on this Dockerfile, add the test service with docker-compose.yml.

■ docker-compose.yml

version: '3'
services:
  app:
    build:
      context: ./app      #Dockerfile storage location
    image: registry.gitlab.com/tamoco-mocomoco/k8s-test/express:latest
    ports:                          #Port connection
      - 3000:5000
    environment:
      PORT: 5000

  test:
    build:
      context: ./test
    environment:
      URL: http://app:5000
      CHECK_STR: "Puyo Puyo"

The environment variable overwrites the URL of the connection destination and the character string to be checked. What should be noted here is that since the connection is made from inside the container, it is ʻapp or the port is 5000, which is the port number in the app. When I ran it with the local python earlier, I was accessing the URL and port number after being transferred with docker-compose`, but it is important to be aware of where to connect from inside the container. Become.

Run the test with docker-comopse (run in the test container)

You can create and test a container with docker-compose.

■ Run the test in a container (success)

$ docker-compose run test
<!DOCTYPE html>
<html>
  <head>
    <title>Puyo Puyo Wadao</title>
    <link rel='stylesheet' href='/stylesheets/style.css' />
  </head>
  <body>
    <h1>Puyo Puyo Wadao</h1>
    <p>Welcome to Puyo Puyo Wadao</p>
  </body>
</html>

It's puyo puyo, so it's okay.

If you run it in a container, you will need to build again if the original source changes. It seems better to add functions such as hot reload (a mechanism that automatically updates the source in the container) here.

By the way, if you want to make the test fail, change the character string Puyo Puyo in ʻapp / express / routes / index.js to peeling `etc. and it will fail.

■ Run the test in a container (failure)

$ docker-compose run test
<!DOCTYPE html>
<html>
  <head>
    <title>Peeling Wadao</title>
    <link rel='stylesheet' href='/stylesheets/style.css' />
  </head>
  <body>
    <h1>Peeling Wadao</h1>
    <p>Welcome to Peeling Wadao</p>
  </body>
</html>

It's not Puyo Puyo, so it's a problem! !!

Incorporate tests into CI / CD pipelines

Add a mechanism to test in a test container to .gitlab-ci.yml. Changed to build the container image if the test passed.

■ .gitlab-ci.yml

image: docker:latest

stages:
  - test
  - build

variables:
  DOCKER_DRIVER: overlay

services:
- docker:dind

before_script:
- docker info
- apk update
- apk upgrade
- apk add docker-compose
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker-compose build

test:
  stage: test
  script:
  - docker-compose up -d app
  - sleep 5s
  - docker-compose run test

build:
  stage: build
  script:
  - docker-compose push

Check Pipeline

It was confirmed that the test was executed as shown in the image below.

コメント 2020-07-16 232531.jpg

If successful, you can see the following execution results.

image.png

If it fails, you can check the execution result as follows.

image.png

Looking back on the third day

Initially, I was preparing a simple test to determine the result by running curl in a shell script. I was expecting a mechanism to add curl to the container on CI and test it by executing ʻapk add curl, but I was a little addicted to it, so I decided to make it smaller with python`.

When actually creating a container for testing, I think it is better to use a container that can execute ʻe2etests such ascypress`.

cypress

Recommended Posts

[Day 3] Study session to deploy from docker-compose to Kubernetes with minimal configuration
From "drawing" to "writing" the configuration diagram: Try drawing the AWS configuration diagram with Diagrams
Create folders from '01' to '12' with python