🤔 Какой опыт работы со 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 должен начинаться с этой инструкции.

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

🤔 Засчёт чего достигается безопасность https?

Безопасность HTTPS достигается за счет шифрования данных с помощью протоколов SSL/TLS, что защищает их от перехвата и изменений. Также используется проверка подлинности серверов через цифровые сертификаты, гарантируя, что пользователь взаимодействует с легитимным сайтом.

🚩Основные компоненты безопасности HTTPS

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

🟠Аутентификация:
Сервер использует цифровой сертификат, выданный доверенным центром сертификации (CA), чтобы подтвердить свою подлинность. Клиент проверяет сертификат и удостоверяется, что общение происходит с настоящим сервером, а не с атакующим.

🟠Целостность данных:
Используются для обеспечения целостности передаваемых данных. Это предотвращает их изменение или повреждение во время передачи.

🟠Защита от атак:
HTTPS защищает от различных видов атак, таких как перехват данных (man-in-the-middle attack) и повторные атаки (replay attacks), благодаря шифрованию и аутентификации.

🚩Процесс установления HTTPS-соединения

1⃣Клиент инициирует соединение:
Клиент (веб-браузер) отправляет запрос на сервер с намерением установить защищённое соединение.

2⃣Сервер отвечает с сертификатом:
Сервер отправляет клиенту свой цифровой сертификат, который включает открытый ключ и информацию о сервере, подписанную центром сертификации (CA).

3⃣Проверка сертификата:
Клиент проверяет сертификат, удостоверяясь, что он был выдан доверенным CA и что сертификат не просрочен или не отозван.

4⃣Установка симметричного ключа:
Клиент генерирует симметричный ключ для сеанса и шифрует его с использованием открытого ключа сервера. Затем клиент отправляет зашифрованный ключ серверу.

5⃣Безопасное соединение:
Сервер расшифровывает симметричный ключ с помощью своего закрытого ключа. Теперь оба участника (клиент и сервер) имеют общий секретный ключ и могут начинать защищённую передачу данных.

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

🤔 На системах какого типа inode могут закончиться?

Inode могут закончиться на файловых системах, где общее количество inode фиксировано при создании файловой системы. Это ограничение обычно встречается в традиционных файловых системах типа ext2, ext3, ext4 и других файловых системах, использующих фиксированное количество inode, определенное при инициализации файловой системы.

🚩Как создаются

Когда файловая система создается (например, с помощью команды mkfs), задается определенное количество inode. Это число определяется на основе размера раздела и коэффициента inode (обычно 1 inode на каждые несколько килобайт дискового пространства). После создания файловой системы количество inode не может быть изменено без переразметки файловой системы, что приведет к потере данных.

Cоздания файловой системы с указанием количества inode
Здесь -i 8192 указывает, что один inode создается на каждые 8192 байта пространства.

mkfs.ext4 -i 8192 /dev/sdX1

🚩Проблема исчерпания

Исчерпание inode может произойти на файловой системе с большим количеством небольших файлов. Например, если у вас есть много маленьких файлов (например, миллионы мелких логов или временных файлов), inode могут закончиться, даже если еще есть свободное место на диске.

🚩Как проверить использование

Вы можете проверить количество используемых и доступных inode с помощью команды df -i:

df -i

Вывод будет примерно таким:

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1     1000000 500000 500000   50% /

🚩Решение проблемы исчерпания

1⃣Удаление ненужных файлов: Удалите ненужные или временные файлы, чтобы освободить inode.
2⃣Создание новой файловой системы: Если проблема серьезная, можно создать новую файловую систему с более высоким коэффициентом inode на доступном пространстве и переместить данные.
3⃣Оптимизация использования пространства: Храните большие файлы вместо большого количества маленьких файлов, когда это возможно.

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

🤔 Что такое DevOps?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚Базу Знанийм

🤔 Что будет если в докерфайле сразу указать и entry point и cmd?

В Dockerfile можно указать как ENTRYPOINT, так и CMD. Они оба определяют, какая команда будет выполнена при запуске контейнера, но имеют разные цели и взаимодействие между собой.

🚩`ENTRYPOINT` и `CMD` в Dockerfile

🟠`ENTRYPOINT`:
Устанавливает основную команду и аргументы, которые не могут быть переопределены во время запуска контейнера с помощью docker run, за исключением явного использования опции --entrypoint.

🟠`CMD`:
Устанавливает команду и аргументы по умолчанию для запуска контейнера. Эти параметры могут быть переопределены при запуске контейнера, если передать другие аргументы в docker run.

🚩Совместное использование

Когда в Dockerfile указаны оба, ENTRYPOINT и CMD, они работают совместно. CMD предоставляет аргументы по умолчанию для команды, указанной в ENTRYPOINT. Таким образом, CMD будет использоваться в качестве аргументов для ENTRYPOINT, если при запуске контейнера не указаны другие аргументы.

FROM ubuntu:latest

ENTRYPOINT ["echo"]
CMD ["Hello, World!"]

🚩Основные сценарии использования

🟠Фиксированная команда с изменяемыми аргументами:
ENTRYPOINT используется для фиксированной команды, которую контейнер должен всегда выполнять, а CMD для указания аргументов по умолчанию.
🟠Предоставление аргументов по умолчанию:
CMD используется для задания аргументов по умолчанию для команды, указанной в ENTRYPOINT.

🚩Взаимодействие с `docker run`

🟠Если указан только ENTRYPOINT, то команда и аргументы из ENTRYPOINT будут выполнены при запуске контейнера.
🟠Если указан только CMD, то команда и аргументы из CMD будут выполнены при запуске контейнера.
🟠Если указаны оба, то команда из ENTRYPOINT будет выполнена с аргументами из CMD по умолчанию. Если при запуске контейнера указать дополнительные аргументы, они заменят аргументы из CMD.

FROM python:3.9

ENTRYPOINT ["python", "-m"]
CMD ["http.server"]

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

🤔 Какие задачи выполнял с использованием Terraform?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Чем юниксовая система отличается от линуксовой?

Unix и Linux — это две операционные системы, которые часто сравнивают из-за их схожести и общего происхождения. Однако у них есть значительные различия, касающиеся их истории, лицензирования, архитектуры и использования.

🚩Основные отличия между Unix и Linux

🟠Лицензирование
Unix: Большинство версий Unix являются коммерческими и проприетарными. Для их использования требуется лицензия. Некоторые версии, такие как BSD (Berkeley Software Distribution), являются открытыми и лицензируются по лицензии BSD.
Linux: Распространяется по лицензии GNU General Public License (GPL), что означает, что он бесплатен и открыт для использования, модификации и распространения. Исходный код доступен всем, что позволяет пользователям вносить изменения и улучшения.

🟠Архитектура и компоненты
Unix: Часто имеют монолитное ядро, где основные системные службы интегрированы в одно ядро. Обеспечивает многозадачность, многопользовательский режим и защищенную память. Включает стандартные утилиты и шеллы, такие как Bourne Shell (sh).
Linux: Также имеет монолитное ядро, но с модульной архитектурой, что позволяет загружать и выгружать модули в ядро без перезагрузки системы. Включает широкий набор утилит и инструментов GNU, таких как Bash (Bourne Again Shell).

🟠Совместимость и стандарты
Unix: Следуют стандартам POSIX (Portable Operating System Interface), что обеспечивает совместимость между различными версиями Unix. Существует несколько проприетарных версий Unix.
Linux: Также совместим с POSIX, что обеспечивает высокую степень совместимости с Unix-системами. Существует множество дистрибутивов Linux (Debian, Ubuntu, CentOS, Fedora и т.д.), каждый из которых имеет свои особенности и наборы пакетов, но все они основаны на общем ядре Linux.

🟠Применение и популярность
Unix: Используется в крупных корпоративных и научных средах. Часто применяется в критически важных системах благодаря своей надежности и стабильности.
Linux: Широко используется в серверах, суперкомпьютерах, встраиваемых системах, настольных ПК и мобильных устройствах (например, Android). Популярен среди разработчиков и энтузиастов благодаря своей открытости, гибкости и сообществу.

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

🤔 Чем отличается COPY от ADD?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний