IT Cloud. Eugeny Shtoltc

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

СКАЧАТЬ to be seamlessly transferred between the scope, which especially relevant for the development pipeline: developer server, test server, and production server. Scopes are set in the cluster context file $ HOME / .kube / config using the kubectl config view command . So, in my cluster context entry, the scope entry does not appear (default is default ):

      – context:

      cluster: gke_essch_europe-north1-a_bitrix

      user: gke_essch_europe-north1-a_bitrix

      name: gke_essch_europe-north1-a_bitrix

      You can see something like this:

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl config view -o jsonpath = '{. contexts [4]}'

      {gke_essch_europe-north1-a_bitrix {gke_essch_europe-north1-a_bitrix gke_essch_europe-north1-a_bitrix []}}

      Let's create a new context for this user and cluster:

      esschtolts @ cloudshell: ~ (essch) $ kubectl config set-context dev \

      > –namespace = development \

      > –cluster = gke_essch_europe-north1-a_bitrix \

      > –user = gke_essch_europe-north1-a_bitrix

      Context "dev" modified.

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl config set-context dev \

      > –namespace = development \

      > –cluster = gke_essch_europe-north1-a_bitrix \

      > –user = gke_essch_europe-north1-a_bitrix

      Context "dev" modified.

      As a result, the following was added:

      – context:

      cluster: gke_essch_europe-north1-a_bitrix

      namespace: development

      user: gke_essch_europe-north1-a_bitrix

      name: dev

      Now it remains to switch to it:

      esschtolts @ cloudshell: ~ (essch) $ kubectl config use-context dev

      Switched to context "dev".

      esschtolts @ cloudshell: ~ (essch) $ kubectl config current-context

      dev

      esschtolts @ cloudshell: ~ (essch) $ kubectl get pods

      No resources found.

      esschtolts @ cloudshell: ~ (essch) $ kubectl get pods –namespace = default

      NAMEREADY STATUS RESTARTS AGE

      Nginxlamp-b5dcb7546-krkm2 1/1 Running 0 10h

      You could add a namespace to the existing context:

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl config set-context $ (kubectl config current-context) –namespace = development

      Context "gke_essch_europe-north1-a_bitrix" modified.

      Now create a new cluster in the scope dev (it is now the default, and it can be omitted –namespace = dev ) and removed from the field by default visibility default (it is no longer the default for our cluster, and it is necessary to specify –namespace = default ):

      esschtolts @ cloudshell: ~ (essch) $ cd bitrix /

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl create -f deploymnet.yaml -f loadbalancer.yaml

      deployment.apps "Nginxlamp" created

      service "frontend" created

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl delete -f deploymnet.yaml -f loadbalancer.yaml –namespace = default

      deployment.apps "Nginxlamp" deleted

      service "frontend" deleted

      esschtolts @ cloudshell: ~ / bitrix (essch) $ kubectl get pods

      NAMEREADY STATUS RESTARTS AGE

      Nginxlamp-b5dcb7546-8sl2f 1/1 Running 0 1m

      Now let's look at the external IP address and open the page:

      esschtolts @ cloudshell: ~ / bitrix (essch) $ curl $ (kubectl get -f loadbalancer.yaml -o json

      | jq -r .status.loadBalancer.ingress [0] .ip) 2> / dev / null | grep '<h2>'

      <h2> Welcome to github.com/mattrayner/docker-lamp "target =" _blank "> Docker-Lamp aka mattrayner / lamp </ h2>

      Customization

      Now we need to change the standard solution to our needs, namely, add configs and our application. For simplicity's sake, we'll mark (change the default) .htaccess file at the root of our application , making it simple to place our application in the / app folder . The first thing that begs to be done is to create a POD and then copy our application from the host to the container (I took Bitrix):

      While this solution works, it has a number of significant disadvantages. The first thing is that we need to wait from outside by constantly polling the POD when it will raise the container and we will copy the application into it and should not do this if the container has not been raised, as well as handle the situation when it breaks our POD, external services, can rely on the status of the POD, although the POD itself will not be ready yet until the script is executed. The second drawback is that we have some kind of external script that needs to be logically not separated from the POD, but at the same time it needs to be manually launched from outside, where it is stored and somewhere there should be instructions for its use. And finally, we can have a lot of these PODs. At first glance, the logical solution is to put the code in the Dockerfile:

      esschtolts @ cloudshell: ~ / bitrix (essch) $ cat Dockerfile

      FROM mattrayner / lamp: latest-1604-php5

      MAINTAINER ESSch [email protected]>

      RUN cd / app / && (\

      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 \

      ) && cd ..;

      EXPOSE 80 3306

      CMD ["/run.sh"]

      esschtolts @ cloudshell: ~ / bitrix (essch) СКАЧАТЬ