IT Cloud. Eugeny Shtoltc

Чтение книги онлайн.

СКАЧАТЬ Successfully

      Successfully built f76e656dac53

      Successfully tagged essch / app: 0.12

      esschtolts @ cloudshell: ~ / bitrix (essch) $ docker image push essch / app | grep digest

      0.12: digest: sha256: 75c92396afacefdd5a3fb2024634a4c06e584e2a1674a866fa72f8430b19ff69 size: 11309

      esschtolts @ cloudshell: ~ / bitrix (essch) $ cat deploymnet.yaml

      apiVersion: apps / v1

      kind: Deployment

      metadata:

      name: Nginxlamp

      namespace: development

      spec:

      selector:

      matchLabels:

      app: lamp

      replicas: 1

      template:

      metadata:

      labels:

      app: lamp

      spec:

      containers:

      – name: lamp

      image: essch / app: 0.12

      ports:

      – containerPort: 80

      esschtolts @ cloudshell: ~ / bitrix (essch) $ IMAGE = essch / app: 0.12 kubectl create -f deploymnet.yaml

      deployment.apps "Nginxlamp" created

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl get pods -l app = lamp

      NAME READY STATUS RESTARTS AGE

      Nginxlamp-55f8cd8dbc-mk9nk 1/1 Running 0 5m

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl exec Nginxlamp-55f8cd8dbc-mk9nk – ls / app /

      index.php

      This happens because the developer of the images, which is correct and written in his documentation, expected that the image would be mounted to the host and the app folder was deleted in the script launched at the end. Also, in this approach, we will face the problem of constant updates of images, config (we cannot set the image number of a variable, since it will be executed on the cluster nodes) and container updates, we also cannot update the folder, since when the container is recreated, the changes will be returned to the original state.

      The correct solution would be to mount the folder and include in the POD lifecycle the launch of the container, which starts in front of the main container and performs preparatory environment operations, often downloading the application from the repository, building, running tests, creating users and setting rights. For each operation, it is correct to launch a separate init container, in which this operation is the basic process, which are executed sequentially – by a chain that will be broken if one of the operations is performed with an error (it will return a non-zero process termination code). For such a container, a separate description is provided in the POD – InitContainer , listing them sequentially, they will build a chain of init container launches in the same order. In our case, we created an unnamed volume and, using InitContainer, delivered the installation files to it. After the successful completion of InitContainer , of which there may be several, the main one starts. The main container is already mounted in our volume, which already has the installation files, we just need to go to the browser and complete the installation:

      esschtolts @ cloudshell: ~ / bitrix (essch) $ cat deploymnet.yaml

      kind: Deployment

      metadata:

      name: Nginxlamp

      namespace: development

      spec:

      selector:

      matchLabels:

      app: lamp

      replicas: 1

      template:

      metadata:

      labels:

      app: lamp

      spec:

      initContainers:

      – name: init

      image: ubuntu

      command:

      – / bin / bash

      – -c

      – |

      cd / app

      apt-get update && apt-get install -y wget

      wget https://www.1c-bitrix.ru/download/small_business_encode.tar.gz

      tar -xf small_business_encode.tar.gz

      sed -i '5i php_value short_open_tag 1' .htaccess

      chmod -R 0777.

      sed -i 's / # php_value display_errors 1 / php_value display_errors 1 /' .htaccess

      sed -i '5i php_value opcache.revalidate_freq 0' .htaccess

      sed -i 's / # php_flag default_charset UTF-8 / php_flag default_charset UTF-8 /' .htaccess

      volumeMounts:

      – name: app

      mountPath: / app

      containers:

      – name: lamp

      image: essch / app: 0.12

      ports:

      – containerPort: 80

      volumeMounts:

      – name: app

      mountPath: / app

      volumes:

      – name: app

      emptyDir: {}

      You can watch events during POD creation with the watch kubectl get events command , and kubectl logs {ID_CONTAINER} -c init or more universally:

      kubectl logs $ (kubectl get PODs -l app = lamp -o JSON | jq ".items [0] .metadata.name" | sed 's / "// g') -c init

      It is advisable to choose small images for single tasks, for example, alpine: 3.5 :

      esschtolts @ cloudshell: ~ (essch) $ docker pull alpine 1> \ dev \ null

      esschtolts @ cloudshell: ~ (essch) $ docker pull ubuntu 1> \ dev \ null

      esschtolts @ cloudshell: ~ (essch) $ docker СКАЧАТЬ