IT Cloud. Eugeny Shtoltc

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 images

      REPOSITORY TAGIMAGE ID CREATED SIZE

      ubuntu latest 93fd78260bd1 4 weeks ago 86.2MB

      alpine latest 196d12cf6ab1 3 months ago 4.41MB

      By slightly changing the code, we significantly saved on the size of the image:

      image: alpine: 3.5

      command:

      – / bin / bash

      – -c

      – |

      cd / app

      apk –update add wget && rm -rf / var / cache / apk / *

      tar -xf small_business_encode.tar.gz

      rm -f small_business_encode.tar.gz

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

      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

      chmod -R 0777.

      volumeMounts:

      There are also minimalistic images with pre-installed packages such as APIne with git: axeclbr / git and golang: 1-alpine .

      Ways to ensure fault tolerance

      Any process can crash. In the case of a container, if the main process crashes, then the container containing it also crashes. It is normal for the crash to occur during graceful shutdown. For example, our application in the container makes a backup of the database, in this case, after the container is executed, we get the work done. For demonstration purposes, let's take the sleep command:

      vagrant @ ubuntu: ~ $ sudo docker pull ubuntu> / dev / null

      vagrant @ ubuntu: ~ $ sudo docker run -d ubuntu sleep 60

      0bd80651c6f97167b27f4e8df675780a14bd9e0a5c3f8e5e8340a98fc351bc64

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES

      0bd80651c6f9 ubuntu "sleep 60" 15 seconds ago Up 12 seconds distracted_kalam

      vagrant @ ubuntu: ~ $ sleep 60

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES

      vagrant @ ubuntu: ~ $ sudo docker ps -a | grep ubuntu

      0bd80651c6f9 ubuntu "sleep 60" 4 minutes ago Exited (0) 3 minutes ago distracted_kalam

      In the case of backups, this is the norm, but in the case of applications that should not be terminated, it is not. A typical trick is a web server. The easiest thing in this case is to restart it:

      vagrant @ ubuntu: ~ $ sudo docker run -d –restart = always ubuntu sleep 10

      c3bc2d2e37a68636080898417f5b7468adc73a022588ae073bdb3a5bba270165

      vagrant @ ubuntu: ~ $ sleep 30

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS

      c3bc2d2e37a6 ubuntu sleep 10 "46 seconds ago Up 1 second

      We see that when the container falls, it restarts. As a result – we always have an application in two states – raised or raised. If a web server crashes from some rare error, this is the norm, but most likely there is an error in processing requests, and it will crash on every such request, and in monitoring we will see a raised container. Such a web server is better dead than half alive. But, at the same time, a normal web server may not start due to rare errors, for example, due to the lack of connection to the database due to network instability. In such a case, the application must be able to handle errors and exit. And in case of a crash due to code errors, do not restart to see the inoperability and send it to the developers for repair. In the case of a floating error, you can try several times:

      vagrant @ ubuntu: ~ $ sudo docker run -d –restart = on-failure: 3 ubuntu sleep 10

      056c4fc6986a13936e5270585e0dc1782a9246f01d6243dd247cb03b7789de1c

      vagrant @ ubuntu: ~ $ sleep 10

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

      c3bc2d2e37a6 ubuntu "sleep 10" 9 minutes ago Up 2 seconds keen_sinoussi

      vagrant @ ubuntu: ~ $ sleep 10

      vagrant @ ubuntu: ~ $ sleep 10

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

      c3bc2d2e37a6 ubuntu "sleep 10" 10 minutes ago Up 9 seconds keen_sinoussi

      vagrant @ ubuntu: ~ $ sleep 10

      vagrant @ ubuntu: ~ $ sudo docker ps

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

      c3bc2d2e37a6 ubuntu "sleep 10" 10 minutes ago Up 2 seconds keen_sinoussi

      Another aspect is when to consider the container dead. By default, this is a process crash. But, by far, the application does not always crash itself in case of an error in order to allow the container to be restarted. For example, a server may be designed incorrectly and try to download the necessary libraries during its startup, but it does not have this opportunity, for example, due to the blocking of requests by the firewall. In such a scenario, the server can wait a long time if an adequate timeout is not specified. In this case, we need to check the functionality. For a web server, this is a response to a specific url, for example:

      docker