style="font-size:15px;"> Docker-File:
* cleaning caches from package managers: apt-get, pip and others, this cache is not needed in production, only
takes up space and loads the network, but nowadays it is not often not relevant, since there are multi-stage
assembly, but more on that below.
* group commands of the same entities, for example, get APT cache, install programs and uninstall
cache: in one instruction – the code of only programs, with the spaced version – the code of the programs and the cache,
because if you do not delete the cache in one instruction, then it will be saved in the layer, regardless of
follow-up actions.
* separate instructions by frequency of change, so for example, if not split installation
software and code, then when you change something in the code, then instead of using the ready-made
layer with programs, they will be reinstalled, which will entail significant preparation time
image that is critical for developers:
ADD ./app/package.json / app
RUN npm install
ADD ./app / app
Docker alternatives
** Rocket or rkt – containers for the CoreOS operating environment from RedHut, specially designed to use containers.
** Hyper-V is an environment for running Docker on the Windows operating system, which is a wrapper (lightweight virtual machine) of the container.
Docker has branched off its core components, which it uses as primitives, which have become standard components for implementing containers such as RKT, bundled into the containerd project:
* CRI-O – OpanSource project aimed from the beginning to fully support CRI (Container Runtime Interface) standards, github.com/opencontainers/runtime-spec/">Runtime Specification and github.com/opencontainers/image-spec">Image Specification as a general interface for the interaction of the orchestration system with containers. Along with Docker, support for CRI-O 1.0 has been added to Kubernetes (more on this) since version 1.7 in 2007, as well as MiniKube and Kubic. Has a CLI (Common Line Interface) implementation in the Pandom project, which almost completely repeats Docker commands, but without orchestration (Docker Swarm), which is the default tool in Linux Fedora.
* CRI (Kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-Kubernetes/">Container Runtime Interface) – an environment for running containers, universally providing primitives (Executor, Supervisor, Metadata, Content, Snapshot , Events and Metrics) for working with Linux containers (process spaces, groups, etc.).
** CNI (Container Networking Interface) – work with the network.
Portainer
The simplest monitoring option would be Portainer:
essh @ kubernetes-master: ~ / microKubernetes $ cat << EOF> docker-compose.monitoring.yml
version: '2'
>
services:
portainer:
image: portainer / portainer
command: -H unix: ///var/run/Docker.sock
restart: always
ports:
– 9000: 9000
volumes:
– /var/run/Docker.sock:/var/run/Docker.sock
– ./portainer_data:/data
>
EOF
essh @ kubernetes-master: ~ / microKubernetes $ docker-compose -f docker-compose.monitoring.yml up -d
Monitoring with Prometheus
Monitoring – maintaining the continuity of work, tracking the current situation (identifying, localizing and sending about the incident, for example, in SaaS PagerDuty), predicting possible situations, visualization, building models for the normal operation of IAOps (Artificial Intelligence For It Operations, https: //www.gartner .com / en / information-technology / glossary / aiops-artificial-intelligence-operations).
Monitoring contains the following steps:
* identification of the incident;
* notification of the incident;
* localization;
* decision.
Monitoring can be classified by level into the following types:
* infrastructure (operating system, servers, Kubernetes, DBMS),;
* applied (application logs, traces, application events),;
* business processes (points in transactions, traces of transactions).
Monitoring can be classified according to the principle:
* distributed (traces),;
* synthetic (availability),;
* IAOps (forecasting, anomalies).
Monitoring is divided into two parts according to the degree of analysis: logging systems and incident investigation systems. An example of logging
serves as ELK stack, and incident investigation – Sentry (SaaS). For micro-services, a tracing system is also added.
requests such as Jeger or Zipkin. The logging system simply writes all the logs that are available.
The incident investigation system writes much more information, but writes it only in case of errors in the application, for example,
environment parameters, versions of installed packages, stack trace and so on, which allows you to get maximum information when viewing
by mistake, rather than collecting it piece by piece from the server and the GIT repository. But the set and format of information depends on the environment, therefore
the incident system needs to be integrated with various language platforms, and even better with specific frameworks. So Sentry
poisons environment variables, a piece of code and an indication of where the error occurred, parameters of the program and platform
environments, method calls.
Ecosystem monitoring can be divided into:
* Built into Cloud Cloud: Azure Monitoring, Amazon CloudWatch, Google Cloud Monitoring
* Provided as a service with support for various SaaS integrations: DataDog, NewRelic
* CloudNative: Prometheus
*
