🤔 Почему сейчас systemd используется чаще чем init?

Systemd стала основной системой инициализации для Unix-подобных ОС, управляя процессами и службами при загрузке и вытеснив традиционные системы, такие как System V init.

🚩Основные преимущества systemd

🟠Параллельная загрузка сервисов:
init: Выполняет задачи инициализации последовательно, что может замедлять процесс загрузки.
systemd: Поддерживает параллельную загрузку сервисов, что значительно ускоряет процесс загрузки системы.

🟠Управление зависимостями:
init: Ограниченные возможности управления зависимостями между сервисами.
systemd: Предоставляет сложное управление зависимостями, автоматически определяя порядок запуска и останова сервисов.

🟠Мониторинг и перезапуск сервисов:
init: Ограниченные возможности мониторинга и автоматического перезапуска упавших сервисов.
systemd: Встроенные функции для мониторинга состояния сервисов и автоматического их перезапуска в случае сбоя.

🟠Унификация конфигурации:
init: Различные дистрибутивы могут использовать разные форматы и скрипты инициализации.
systemd: Стандартизированный формат конфигурационных файлов (unit-файлов), что упрощает администрирование и переносимость.

🟠Журналирование:
init: Использует отдельные инструменты для журналирования, такие как syslog.
systemd: Встроенная система журналирования (journald), которая объединяет логи всех сервисов и предоставляет мощные возможности для их анализа.

🟠Управление состоянием системы:
init: Ограниченные возможности управления состоянием системы, такими как спящий режим, гибернация и выключение.
systemd: Встроенные команды для управления состоянием системы, такие как systemctl suspend, systemctl hibernate и systemctl poweroff.

🚩Примеры использования systemd

Запуск и остановка сервисов:

systemctl start httpd.service

Остановка сервиса:

systemctl stop httpd.service     

Проверка статуса сервиса:

systemctl status httpd.service   

Включение автозапуска:

systemctl enable httpd.service    

Отключение автозапуска:

systemctl disable httpd.service     

Пример unit-файла для сервиса Nginx:

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
[Service]
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/usr/sbin/nginx -s quit
PIDFile=/run/nginx.pid
Restart=always
[Install]
WantedBy=multi-user.target

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему если поставить докер и создать образ он может не запускаться в чем может быть причина?

🟠Ошибки в Dockerfile
Ошибки в синтаксисе или логике Dockerfile могут приводить к созданию некорректного образа. Если указаны неверные пути или отсутствуют необходимые файлы, образ может не работать. Если директория app/ отсутствует, команда COPY завершится с ошибкой.

COPY app/ /usr/src/app
CMD ["python", "/usr/src/app/app.py"]

🟠Отсутствие зависимостей
Если необходимые библиотеки или пакеты не установлены, приложение не сможет запуститься. Если app.py требует внешних библиотек, их нужно установить с помощью RUN pip install.

FROM python:3.8
COPY app.py /
CMD ["python", "/app.py"]

🟠Неправильная рабочая директория
Если не указана правильная рабочая директория, команды могут выполняться в неверном контексте. Если не указать WORKDIR /app, Node.js не сможет найти index.js.

FROM node:14
COPY . /app
WORKDIR /app
CMD ["node", "index.js"]

🟠Ошибки конфигурации
Отсутствие или неправильная настройка переменных окружения может приводить к сбоям. Если контейнер слушает на порту, который не открыт, он не будет доступен извне. Если default.conf имеет ошибки конфигурации, Nginx не запустится.

FROM nginx
COPY default.conf /etc/nginx/conf.d/

🟠Проблемы с правами доступа
Если файлы или директории имеют неправильные права доступа, приложение может не запуститься. Некоторые приложения требуют выполнения от имени определенного пользователя. Если nobody не имеет права выполнения скрипта, контейнер не запустится.

FROM ubuntu
COPY script.sh /
RUN chmod +x /script.sh
USER nobody
CMD ["/script.sh"]

🟠Недостаток ресурсов
Недостаток памяти или процессорного времени может привести к сбою при запуске контейнера. Если приложение требует больше памяти, оно не запустится.

docker run -m 256m myapp

🟠Проблемы с сетью
Неправильная настройка сетевых интерфейсов или зависимость от внешних сервисов может привести к сбоям. Если приложение требует доступа к сети, оно не запустится без сетевого интерфейса.

docker run --network=none myapp

🟠Логи и диагностика
Используйте команды docker logs и docker inspect для диагностики проблем.

docker logs <container_id>
docker inspect <container_id>

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие команды порождают слой?

В Docker образ состоит из нескольких слоев, каждый из которых представляет собой изменения, внесенные в файловую систему контейнера. Эти слои создаются при выполнении команд в Dockerfile. Слои позволяют эффективно использовать кэширование и делиться образами. Основные команды, которые создают слои, включают:

🚩Команды и их влияние

FROM — это первая команда в Dockerfile, которая указывает базовый образ для последующих инструкций. Каждый FROM создает новый базовый слой.

FROM ubuntu:20.04

RUN — эта команда выполняет команды в новом слое поверх текущего образа и создает новый образ. Часто используется для установки пакетов и выполнения скриптов.

RUN apt-get update && apt-get install -y python3

COPY — эта команда копирует файлы и директории из контекста сборки (локальной файловой системы) в файловую систему контейнера. Она создает новый слой с добавленными или измененными файлами.

COPY . /app

ADD — аналогична команде COPY, но с дополнительными возможностями. Она может извлекать архивы и загружать файлы из URL. Эта команда также создает новый слой.

ADD myfile.tar.gz /app

🚩Команды, не создающие новые слои

- CMD: Определяет команду по умолчанию для выполнения при запуске контейнера.
- ENTRYPOINT: Устанавливает исполняемую команду для контейнера.
- ENV: Устанавливает переменные окружения.
- EXPOSE: Указывает на порты, которые контейнер будет слушать.
- WORKDIR: Устанавливает рабочую директорию для последующих команд.

ENV PATH=/app/bin:$PATH
EXPOSE 8080
WORKDIR /app

🚩Кэширование слоев

Docker использует кэширование для ускорения сборки образов. Если инструкция и контекст для команды не изменились, Docker использует закэшированный слой вместо создания нового.

# Если requirements.txt не изменился, этот слой будет закэширован
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt

# Остальные файлы копируются
COPY . /app

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему плохо запускать контейнер от рута?

Запуск контейнеров от имени пользователя root (рута) в Docker является обычной практикой, но это может привести к серьезным проблемам безопасности. Вот основные причины, почему это считается плохой практикой:

🟠Повышение рисков безопасности:
Эксплуатация уязвимостей: Если злоумышленник получает доступ к контейнеру, запущенному от имени root, он может легко использовать уязвимости контейнера для атаки на хост-систему.
Злоумышленники: Контейнеры могут содержать уязвимые или злонамеренные коды, которые при запуске с привилегиями root могут получить доступ к чувствительной информации или вызвать сбои.

🟠Отсутствие изоляции:
Гостевая изоляция: Контейнеры должны быть изолированы от хост-системы. Запуск контейнера от имени root нарушает эту изоляцию, так как root внутри контейнера — это также root на хосте.
Повышенные привилегии: Контейнеры, запущенные от имени root, могут иметь доступ к системным ресурсам, что увеличивает риск нарушения безопасности.

🟠Нарушение принципа наименьших привилегий:
Принцип наименьших привилегий: Этот принцип гласит, что процесс должен иметь только те привилегии, которые необходимы для выполнения его задач. Запуск контейнера от имени root нарушает этот принцип, предоставляя ему избыточные права.

🚩Примеры проблем

🟠Повышение привилегий:
Если в контейнере, запущенном от имени root, найдена уязвимость, злоумышленник может использовать ее для выполнения команд с привилегиями root на хосте, что может привести к серьезным нарушениям безопасности.

🟠Доступ к файловой системе хоста:
Контейнер, запущенный от имени root, может получить доступ к критически важным файлам хостовой системы, изменять их или удалять, что может привести к нарушению работы всей системы.

🚩Как избежать запуска контейнеров от рута

Использование непривилегированных пользователей:
В Dockerfile можно создать пользователя с ограниченными привилегиями и переключиться на него.

FROM ubuntu:20.04
RUN useradd -m myuser
USER myuser
CMD ["myapp"]     

Использование флага --user:
При запуске контейнера можно использовать флаг --user, чтобы указать непривилегированного пользователя.

docker run --user 1000:1000 myapp

Использование механизмов безопасности Docker:
Использование профилей seccomp для ограничения системных вызовов.
Использование AppArmor или SELinux для ограничения доступа контейнеров к системным ресурсам.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой опыт работы со stateful set?

StatefulSet в Kubernetes — это объект, который управляет развертыванием и масштабированием наборов подов, и обеспечивает их уникальные идентификаторы и постоянное хранение данных. .

🚩Основные возможности StatefulSet

🟠Уникальные идентификаторы подов:
Каждый под в StatefulSet имеет стабильный уникальный идентификатор, который сохраняется при перезапусках.
🟠Порядковый запуск и завершение:
Поды запускаются и завершаются в определенном порядке, что важно для приложений.
🟠Стабильные сетевые идентификаторы:
Каждый под имеет постоянное DNS-имя, что упрощает связь между компонентами приложения.
🟠Постоянное хранилище:
StatefulSet использует PersistentVolume (PV) для хранения данных, что обеспечивает сохранение данных при перезапусках или пересоздании подов.

🚩Пример использования

Запуск базы данных
Один из наиболее распространенных случаев использования StatefulSet — это развертывание и управление кластерами баз данных, такими как Cassandra, MySQL или PostgreSQL.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Объяснение полей конфигурации
🟠apiVersion: Версия API Kubernetes для объекта StatefulSet.
🟠kind: Тип объекта, в данном случае StatefulSet.
🟠metadata: Метаинформация о StatefulSet, включая имя.
🟠spec: Спецификация StatefulSet.
🟠serviceName: Имя службы, используемой для управления доступом к подам.
🟠replicas: Количество реплик, которые StatefulSet должен поддерживать.
🟠selector: Метки для выбора подов, управляемых этим StatefulSet.
🟠template: Шаблон пода, включающий метаданные и спецификацию контейнеров.

🚩Опыт использования

1⃣Развертывание кластеров баз данных:
Успешное развертывание и управление кластерами MySQL и Cassandra, обеспечивая высокую доступность и отказоустойчивость.

2⃣Поддержание состояния приложений:
Развертывание приложений, требующих сохранения состояния, таких как Zookeeper и Kafka.

3⃣Порядковое обновление подов:
Управление порядковым обновлением подов для обеспечения правильной последовательности операций и минимизации времени простоя.

4⃣Мониторинг и масштабирование:
Настройка мониторинга состояния подов и автоматическое масштабирование StatefulSet для адаптации к изменяющимся нагрузкам.

🚩Плюсы

➕Стабильность и предсказуемость: StatefulSet обеспечивает стабильные сетевые идентификаторы и уникальные имена для подов, что упрощает управление состоянием.
➕Постоянство данных: Использование PersistentVolume гарантирует, что данные сохраняются между перезапусками подов.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой основной параметр у stateful set?

Это объект, который управляет развертыванием и масштабированием наборов подов с гарантией их уникальных идентификаторов и стабильных сетевых идентификаторов. Основной параметр, который определяет поведение StatefulSet, это `serviceName`.

🚩Основной параметр: serviceName

Это имя службы (Service), связанной с StatefulSet, которая управляет доступом к подам. Эта служба используется для обеспечения стабильных сетевых идентификаторов для подов.

🚩Важные параметры и их функции

replicas:
Определяет количество реплик подов, которые должен поддерживать StatefulSet.

replicas: 3

selector:
Указывает метки, которые должны быть на подах, управляемых StatefulSet.

selector:
matchLabels:
app: myapp     

template:
Шаблон пода, который используется для создания новых реплик.

template:
  metadata:
    labels:
      app: myapp
  spec:
    containers:
    - name: myapp-container
      image: myapp:latest
      ports:
      - containerPort: 80

volumeClaimTemplates:
Шаблоны PersistentVolumeClaim для создания постоянных хранилищ для каждого пода.

volumeClaimTemplates:
- metadata:
    name: myapp-storage
  spec:
    accessModes: [ "ReadWriteOnce" ]
    resources:
      requests:
        storage: 1Gi

🚩Пример конфигурации StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp-statefulset
spec:
  serviceName: "myapp-service"
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - name: myapp-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: myapp-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

🚩Объяснение полей

apiVersion: Версия API Kubernetes для объекта StatefulSet.
kind: Тип объекта, в данном случае StatefulSet.
metadata: Метаинформация о StatefulSet, включая имя.
spec: Спецификация StatefulSet.
serviceName: Имя службы, связанной с StatefulSet, обеспечивающей стабильные сетевые идентификаторы.
replicas: Количество реплик подов.
selector: Метки для выбора подов.
template: Шаблон пода, включающий метаданные и спецификацию контейнеров.
volumeClaimTemplates: Шаблоны для создания PersistentVolumeClaim.

Ставь 👍 и забирай 📚 Базу знаний

🤔 На чём строится изоляция докера?

Изоляция в Docker достигается за счет использования нескольких ключевых технологий и механизмов, которые обеспечивают контейнеры с уровнем изоляции, сопоставимым с виртуальными машинами, но с меньшими накладными расходами. Основные технологии, на которых строится изоляция Docker, включают:

🟠Пространства имен (Namespaces):
PID namespace: Изолирует идентификаторы процессов (PID), позволяя контейнерам иметь свои собственные процессы, которые не видны за пределами контейнера.
Network namespace: Изолирует сетевые интерфейсы, IP-адреса, порты и маршруты контейнера от других контейнеров и хоста.
Mount namespace: Изолирует файловую систему контейнера, позволяя ему видеть только свои собственные файловые системы.
UTS namespace: Изолирует имя хоста и доменное имя, позволяя контейнеру иметь свое собственное имя хоста.
IPC namespace: Изолирует объекты межпроцессного взаимодействия (например, очереди сообщений, семафоры и разделяемую память).
User namespace: Изолирует идентификаторы пользователей и групп, позволяя запускать процессы в контейнере с привилегиями без необходимости предоставлять эти привилегии на хосте.

🟠Контрольные группы (Cgroups):
Контрольные группы управляют использованием ресурсов контейнером, таких как процессорное время, память, дисковый ввод-вывод и сетевые ресурсы. Это позволяет ограничивать и отслеживать потребление ресурсов каждым контейнером, обеспечивая стабильную работу системы.

🟠Union File Systems (UnionFS):
Docker использует UnionFS (например, OverlayFS, AUFS) для создания легковесных и быстрых файловых систем. Это позволяет контейнерам делить общие слои, что значительно снижает использование дискового пространства и ускоряет создание и запуск контейнеров.

🟠Сетевые интерфейсы и мосты (Bridges):
Docker создает изолированные сетевые интерфейсы для каждого контейнера, позволяя им общаться с внешним миром через мостовые интерфейсы (bridges). Это обеспечивает сетевую изоляцию и позволяет создавать сложные сетевые топологии.

🚩Пример настройки изоляции

Рассмотрим пример, где создается контейнер с ограничением ресурсов и изоляцией:

docker run -d --name isolated_container \
  --cpus=".5" \
  --memory="256m" \
  --memory-swap="256m" \
  --hostname="container_host" \
  ubuntu:latest

В этом примере:
--cpus=".5" ограничивает использование процессора до 50%.
--memory="256m" устанавливает лимит использования памяти на 256 MB.
--memory-swap="256m" устанавливает лимит swap памяти на 256 MB.
--hostname="container_host" задает имя хоста контейнера.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие параметры есть в deployment?

Deployment в Kubernetes предоставляет множество параметров, которые можно настроить для управления развертыванием, обновлением и масштабированием приложений. Вот основные параметры, которые можно задать в манифесте Deployment:

🟠apiVersion:
Версия API Kubernetes, используемая для объекта Deployment. Например: apiVersion: apps/v1

🟠kind:
Тип объекта, в данном случае Deployment. Напримерkind: Deployment

🟠metadata:
Метаинформация о Deployment, такая как имя и метки.

metadata:
  name: myapp-deployment
  labels:
    app: myapp  

🟠spec:
Спецификация Deployment, включающая следующие параметры:

🚩Параметры спецификации (spec)

🟠replicas:
Количество реплик подов, которые Deployment должен поддерживать. Например replicas: 3

🟠selector:
Указывает метки, которые должны быть на подах, управляемых этим Deployment.

selector:
  matchLabels:
    app: myapp

🟠template:
Шаблон пода, который используется для создания новых реплик.

template:
  metadata:
    labels:
      app: myapp
  spec:
    containers:
    - name: myapp-container
      image: myapp:latest
      ports:
      - containerPort: 80

🟠strategy:
Определяет стратегию обновления подов.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

🟠minReadySeconds:
Минимальное количество секунд, которое новый под должен быть в состоянии "Ready" перед тем, как он будет считаться доступным. Напримрер, minReadySeconds: 30

🟠revisionHistoryLimit:
Количество старых ReplicaSets, которые нужно сохранить для возможности отката. Например, revisionHistoryLimit: 10

🟠paused:
Указывает, должно ли развертывание быть приостановлено. Например, paused: false

🟠progressDeadlineSeconds:
Максимальное время в секундах, в течение которого развертывание должно завершиться. Например, progressDeadlineSeconds: 600

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что происходит когда вы создаёте сущность deployment?

Когда вы создаете Deployment в Kubernetes, происходит несколько шагов, которые обеспечивают развертывание, обновление и масштабирование ваших приложений.

🚩Основные шаги при создании Deployment

1⃣Определение манифеста Deployment:
Вы создаете YAML или JSON манифест, который описывает свойства Deployment, такие как имя, количество реплик, шаблон пода и стратегию обновления.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:latest
        ports:
        - containerPort: 80

2⃣Применение манифеста Deployment:
Вы применяете манифест с помощью команды kubectl apply -f deployment.yaml.

kubectl apply -f deployment.yaml

3⃣API-сервер принимает запрос:
Kubernetes API-сервер принимает запрос и сохраняет объект Deployment в etcd, который является хранилищем для всей конфигурации кластера.

4⃣Контроллер Deployment:
Контроллер Deployment, работающий в фоновом режиме, обнаруживает новый объект Deployment и начинает его обработку. Он создает ReplicaSet, который управляет подами для этого Deployment.

5⃣Создание ReplicaSet:
Контроллер Deployment создает ReplicaSet с указанным количеством реплик и шаблоном пода. ReplicaSet начинает создавать поды, чтобы достичь желаемого количества реплик.

6⃣Запуск подов:
Kubernetes Scheduler назначает поды на подходящие узлы (ноды) кластера. Kubelet на каждом узле запускает контейнеры в подах, используя указанные образы и настройки.

7⃣Мониторинг состояния:
Контроллер Deployment постоянно мониторит состояние подов и ReplicaSet. Если поды выходят из строя или их количество не соответствует заданному, ReplicaSet восстанавливает нужное количество подов.

8⃣Обновление Deployment:
При изменении манифеста Deployment (например, при обновлении образа контейнера), вы применяете изменения с помощью kubectl apply -f deployment.yaml. Контроллер Deployment создает новый ReplicaSet для новых подов и постепенно заменяет старые поды новыми, следуя стратегии обновления (например, RollingUpdate).

🚩Плюсы

➕Обновления без простоя:
Deployment обеспечивает постепенное обновление подов, минимизируя простой и обеспечивая доступность приложения.
➕Автоматическое восстановление:
При сбое подов Deployment автоматически восстанавливает их, обеспечивая стабильную работу приложения.
➕Масштабирование:
Легко изменять количество реплик приложения для управления нагрузкой, просто обновляя поле replicas в манифесте.
➕Версионирование:
Deployment поддерживает откаты (rollback) к предыдущим версиям, если новая версия приводит к ошибкам.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Когда выполняются пробы?

Пробы выполняются для оценки и проверки возможностей, навыков или функций, обычно в контексте экспериментов, тестирования или практических заданий. Это может касаться научных экспериментов, технических испытаний или проверок навыков в различных сферах, например, на актерских или рабочих прослушиваниях.

🚩Существует три основных типа:

🟠Liveness Probe (Проверка жизнеспособности)
Liveness Probe проверяет, работает ли контейнер. Если проверка liveness не удалась, Kubernetes перезапускает контейнер.

🟠Readiness Probe (Проверка готовности)
Readiness Probe проверяет, готов ли контейнер обслуживать запросы. Если проверка readiness не удалась, под будет исключен из службы (service) и не будет получать трафик.

🟠Startup Probe (Проверка при запуске)
Startup Probe проверяет, что контейнер успешно запустился. Если проверка startup не удалась, Kubernetes считает, что контейнер не может запуститься, и перезапускает его.

🚩Когда они выполняются:

🟠Периодически в течение жизни контейнера, начиная после заданного периода initialDelaySeconds. Используется для проверки состояния контейнеров, которые могут войти в неопределенное состояние и требуют перезапуска для восстановления работоспособности.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
  failureThreshold: 3

🟠Периодически в течение жизни контейнера, начиная после заданного периода initialDelaySeconds. Используется для проверки готовности контейнеров, которые могут быть временно не готовы обслуживать трафик, например, во время загрузки данных или выполнения миграций.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
  failureThreshold: 3

🟠В начале жизни контейнера, начиная с момента запуска и до тех пор, пока проверка не будет успешной или пока не истечет заданное время. Используется для контейнеров, которые могут долго запускаться, что предотвращает преждевременные сбои liveness и readiness проб.

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 30

🚩Механизмы

🟠HTTP GET:
Проверка выполняется путем отправки HTTP GET запроса к контейнеру.

httpGet:
  path: /healthz
  port: 8080

🟠TCP Socket:
Проверка выполняется путем установления TCP-соединения с контейнером.

tcpSocket:
  port: 8080

🟠Exec:
Проверка выполняется путем выполнения команды внутри контейнера.

exec:
  command:
  - cat
  - /tmp/healthy

Ставь 👍 и забирай 📚 Базу знаний

🤔 Без какой инструкции не может существовать докер файл?

FROM — это ключевая инструкция в Dockerfile, без которой файл не может существовать. Она указывает базовый образ, от которого начинается сборка контейнера. Любой Dockerfile должен начинаться с этой инструкции.

Ставь 👍 и забирай 📚 Базу знаний