📌 Что такое init контейнер?

💬 Спрашивают в 13% собеседований

🤔 Что такое Init-контейнер

Init-контейнер — это особый тип контейнера в Kubernetes, который запускается и выполняется перед основными (основными) контейнерами в поде (Pod). Init-контейнеры предназначены для выполнения задач начальной настройки или подготовки среды перед запуском основных контейнеров.

🤔 Основные особенности Init-контейнеров

1️⃣ Запуск перед основными контейнерами:
- Init-контейнеры запускаются последовательно, один за другим.
- Основные контейнеры не запускаются, пока все Init-контейнеры не завершат свою работу успешно.

2️⃣ Изоляция и безопасность:
- Init-контейнеры имеют свою собственную файловую систему, независимую от основных контейнеров.
- Могут использоваться для выполнения задач, требующих повышенных привилегий, минимизируя риск для основных контейнеров.

3️⃣ Повторные запуски:
- Init-контейнеры будут перезапускаться до тех пор, пока не завершатся успешно, или до тех пор, пока не выйдет время ожидания.

4️⃣ Подготовка среды:
- Выполнение задач инициализации, таких как настройка конфигураций, загрузка данных, проверка условий перед запуском приложения.

🤔 Примеры использования Init-контейнеров

1️⃣ Проверка наличия зависимости:
- Перед запуском основного приложения Init-контейнер может проверить наличие необходимых зависимостей или служб.

2️⃣ Загрузка конфигураций:
- Init-контейнер может загружать конфигурационные файлы или секреты из внешних источников.

3️⃣ Выполнение миграций базы данных:
- Перед запуском основного приложения Init-контейнер может выполнить миграции базы данных.

🤔 Пример манифеста Pod с Init-контейнером

Пример Pod, который использует Init-контейнер для выполнения миграций базы данных перед запуском основного приложения:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  initContainers:
  - name: init-migrate
    image: busybox
    command: ['sh', '-c', 'echo "Running database migrations"; sleep 5;']
  containers:
  - name: myapp-container
    image: myapp:latest
    ports:
    - containerPort: 80

В этом примере:
- Init-контейнер init-migrate запускается первым и выполняет команду, которая симулирует выполнение миграций базы данных.
- После успешного завершения Init-контейнера запускается основной контейнер myapp-container.

🤔 Преимущества использования Init-контейнеров

1️⃣ Разделение обязанностей:
- Разделение задач инициализации и основной логики приложения помогает упростить разработку и поддержку.

2️⃣ Повторное использование:
- Init-контейнеры можно повторно использовать в разных Pod-ах, если они выполняют общие задачи подготовки.

3️⃣ Обеспечение готовности среды:
- Init-контейнеры могут гарантировать, что все необходимые условия выполнены до запуска основного приложения.

🤔 Краткое резюме

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Чем отличается git push от git pull и зачем используется каждая?

💬 Спрашивают в 13% собеседований

🤔 Git Push и Git Pull: Отличия и использование

Git — это распределенная система управления версиями, которая позволяет разработчикам отслеживать изменения в коде и работать совместно над проектами. Две ключевые команды в Git, которые часто используются в ежедневной работе — это git push и git pull. Каждая из этих команд имеет свою цель и применяется в разных сценариях.

🤔 Git Push

`git push` — это команда, которая используется для отправки локальных изменений на удаленный репозиторий.

🤔 Основные аспекты:

1️⃣ Отправка изменений:
- git push отправляет коммиты из локального репозитория на удаленный репозиторий.
- Обычно используется для публикации локальных изменений и совместной работы с другими разработчиками.

2️⃣ Синхронизация веток:
- git push обновляет соответствующую ветку на удаленном репозитории, делая ваши изменения доступными для других.

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

# Отправка изменений на удаленный репозиторий
git push origin main

В этом примере команда отправляет коммиты из локальной ветки main на удаленную ветку main репозитория с именем origin.

🤔 Git Pull

`git pull` — это команда, которая используется для получения и слияния изменений из удаленного репозитория в локальный репозиторий.

🤔 Основные аспекты:

1️⃣ Получение изменений:
- git pull загружает изменения из удаленного репозитория в локальный.
- Команда объединяет команды git fetch (для получения изменений) и git merge (для слияния изменений).

2️⃣ Синхронизация локальной ветки:
- git pull обновляет локальную ветку последними изменениями из удаленного репозитория, гарантируя, что ваш локальный репозиторий синхронизирован с удаленным.

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

# Получение и слияние изменений из удаленного репозитория
git pull origin main

В этом примере команда получает изменения из удаленной ветки main репозитория с именем origin и сливает их с локальной веткой main.

🤔 Основные отличия

1️⃣ Направление данных:
- git push: Отправляет изменения с локального репозитория в удаленный репозиторий.
- git pull: Получает изменения из удаленного репозитория в локальный репозиторий.

2️⃣ Цель:
- git push: Публикация локальных изменений для совместной работы.
- git pull: Получение и слияние последних изменений для синхронизации с удаленным репозиторием.

3️⃣ Процесс:
- git push: Простой процесс отправки коммитов.
- git pull: Комбинирует получение и слияние изменений, что может вызывать конфликты, которые необходимо разрешать вручную.

🤔 Когда использовать каждую команду

- `git push` используется, когда вы хотите отправить свои изменения на удаленный сервер, чтобы другие разработчики могли видеть и работать с ними. Это важно для совместной работы над проектом.
- `git pull` используется, когда вы хотите синхронизировать свою локальную копию репозитория с последними изменениями из удаленного репозитория. Это помогает убедиться, что ваш локальный репозиторий содержит актуальные данные, особенно перед началом новой работы или перед слиянием своих изменений.

🤔 Краткое резюме

- `git push`: Команда для отправки локальных изменений в удаленный репозиторий. Используется для публикации изменений.
- `git pull`: Команда для получения и слияния изменений из удаленного репозитория в локальный. Используется для синхронизации с удаленным репозиторием.

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какой опыт работы с постгрес?

💬 Спрашивают в 13% собеседований

🤔 Опыт работы с PostgreSQL

🤔 Общий опыт

PostgreSQL — это мощная реляционная база данных с открытым исходным кодом, известная своей расширяемостью и соответствием стандартам SQL. У меня есть значительный опыт работы с PostgreSQL, охватывающий различные аспекты разработки, администрирования и оптимизации баз данных.

🤔 Проектирование и создание схем

- Опыт: Проектирование баз данных с учетом требований приложения, нормализация данных, создание таблиц, индексов и ограничений.

- Пример: Создание схемы базы данных для системы управления заказами с таблицами для пользователей, продуктов, заказов и платежей.

-- Создание таблицы пользователей
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Создание таблицы продуктов
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

🤔 Оптимизация запросов

- Опыт: Анализ и оптимизация SQL-запросов для повышения производительности, использование индексов, планов выполнения запросов (EXPLAIN), материализованных представлений.

- Пример: Оптимизация запросов для отчетов, использующих большие объемы данных, путем добавления индексов и переписывания запросов для более эффективного выполнения.

-- Пример индексации
CREATE INDEX idx_users_email ON users(email);

-- Пример использования EXPLAIN для анализа запроса
EXPLAIN SELECT * FROM users WHERE email = '[email protected]';

🤔 Администрирование баз данных

- Опыт: Настройка и управление PostgreSQL-серверами, создание резервных копий и восстановление, настройка репликации и высокодоступных конфигураций.

- Пример: Настройка потоковой репликации для обеспечения отказоустойчивости и высокой доступности.

# Создание резервной копии базы данных
pg_dump -U username -h localhost -F c mydatabase > mydatabase.backup

# Восстановление базы данных из резервной копии
pg_restore -U username -h localhost -d mydatabase mydatabase.backup

🤔 Написание хранимых процедур и функций

- Опыт: Создание хранимых процедур и функций с использованием PL/pgSQL для автоматизации сложных бизнес-логик на стороне базы данных.

- Пример: Написание функции для расчета общей стоимости заказов для пользователя.

-- Пример хранимой функции
CREATE OR REPLACE FUNCTION get_total_spent(user_id INT) RETURNS DECIMAL AS $$
DECLARE
    total DECIMAL;
BEGIN
    SELECT SUM(price) INTO total
    FROM orders
    WHERE user_id = get_total_spent.user_id;
    RETURN total;
END;
$$ LANGUAGE plpgsql;

🤔 Работа с расширениями

- Опыт: Использование расширений для расширения функциональности PostgreSQL, таких как PostGIS для геопространственных данных или pg_trgm для быстрого поиска текста.

- Пример: Установка и использование расширения PostGIS для работы с геопространственными данными.

-- Установка расширения PostGIS
CREATE EXTENSION postgis;

-- Пример использования PostGIS
SELECT ST_AsText(ST_MakePoint(-71.064544, 42.28787));

🤔 Инструменты и среды

- Опыт: Использование различных инструментов для работы с PostgreSQL, включая pgAdmin, psql, DBeaver и другие инструменты для мониторинга и администрирования.

- Пример: Использование pgAdmin для управления базой данных и выполнения запросов, а также настройки пользователей и ролей.

🤔 Краткое резюме

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

🤔 Что за сущность такая оператор зачем нужна?

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

🚩Основные компоненты оператора

🟠Custom Resource Definitions (CRD): CRD расширяют стандартные объекты Kubernetes, добавляя новые типы ресурсов. Эти ресурсы специфичны для приложений или сервисов, которыми управляет оператор.
🟠Контроллер: Контроллер — это программа, которая следит за состоянием ресурсов, определенных CRD, и выполняет действия для достижения желаемого состояния. Контроллеры пишутся на Go с использованием фреймворка Operator SDK.

🚩Зачем нужны операторы

🟠Автоматизация сложных задач: Операторы автоматизируют рутинные задачи, такие как развертывание, обновление, резервное копирование и восстановление приложений, которые требуют знаний и вмешательства администратора.
🟠Управление состоянием приложений: Операторы следят за состоянием приложения и автоматически предпринимают действия для поддержания или восстановления этого состояния, обеспечивая высокую доступность и отказоустойчивость.
🟠Интеграция с Kubernetes: Операторы используют встроенные механизмы Kubernetes, такие как CRD и контроллеры, что позволяет легко интегрировать их в существующие кластеры Kubernetes и управлять приложениями в привычной среде.

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

🟠Базы данных: Оператор для PostgreSQL может автоматизировать задачи развертывания кластеров, настройки репликации, выполнения резервного копирования и восстановления.
🟠Мониторинг и логирование: Оператор для Prometheus может управлять развертыванием и настройкой экземпляров Prometheus, включая настройку сбора метрик и алертинга.
🟠CI/CD: Оператор для Jenkins может автоматизировать настройку мастера Jenkins и агентов, а также управлять плагинами и настройками.

🚩Определение CRD

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: postgresqls.postgres.example.com
spec:
  group: postgres.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: postgresqls
    singular: postgresql
    kind: PostgreSQL
    shortNames:
      - pg

🚩Разработка контроллера

func (r *ReconcilePostgreSQL) Reconcile(request reconcile.Request) (reconcile.Result, error) {
    instance := &v1alpha1.PostgreSQL{}
    err := r.client.Get(context.TODO(), request.NamespacedName, instance)
    if err != nil {
        return reconcile.Result{}, err
    }
   return reconcile.Result{}, nil
}

🚩Развертывание оператора

operator-sdk init --domain example.com --repo github.com/example/postgresql-operator
operator-sdk create api --group postgres --version v1 --kind PostgreSQL --resource --controller
make install
make run

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

🤔 Как работает gitlab runner?

GitLab Runner — это приложение с открытым исход кодом, используемое для выполнения задач CI/CD в проектах GitLab. Оно отвечает за выполнение заданий (jobs), определенных в файле .gitlab-ci.yml, и за передачу результатов обратно в GitLab.

🚩Основные компоненты и архитектура

🟠GitLab: Центральный сервер, где хранятся репозитории, настройки проектов и пайплайны CI/CD.
🟠GitLab Runner: Агент, который устанавливается на отдельный сервер или виртуальную машину и выполняет задачи CI/CD.
🟠Executor: Способ выполнения заданий Runner-ом, такие как Docker, Shell, VirtualBox, Kubernetes и другие.

🚩Установка и настройка GitLab Runner

Установка GitLab Runner зависит от операционной системы. Пример для Ubuntu:

GitLab Runner
curl -L --output /usr/share/keyrings/gitlab-runner-archive-keyring.gpg https://packages.gitlab.com/runner/gitlab-runner/gpgkey
echo "deb [signed-by=/usr/share/keyrings/gitlab-runner-archive-keyring.gpg] https://packages.gitlab.com/runner/gitlab-runner/ubuntu/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/gitlab-runner.list
Runner
sudo apt-get update
sudo apt-get install gitlab-runner

После установки GitLab Runner нужно зарегистрировать его в GitLab для связи с проектом:

sudo gitlab-runner register

Во время регистрации нужно указать:
🟠URL GitLab сервера.
🟠Токен регистрации (доступен в настройках GitLab проекта).
🟠Описание и метки Runner-а.
🟠Тип Executor-а (например, Shell, Docker).

Пример регистрации

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com/
Please enter the gitlab-ci token for this runner:
<TOKEN>
Please enter the gitlab-ci description for this runner:
[hostname] my-runner
Please enter the gitlab-ci tags for this runner (comma separated):
docker,aws
Please enter the executor: shell, docker, docker-ssh, ssh, docker+machine, kubernetes, custom:
docker

Конфигурация файла .gitlab-ci.yml: Файл .gitlab-ci.yml определяет этапы (stages) и задания (jobs) пайплайна CI/CD. Пример простого файла:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - ./build.sh
test_job:
  stage: test
  script:
    - echo "Running tests..."
    - ./test.sh
deploy_job:
  stage: deploy
  script:
    - echo "Deploying the project..."
    - ./deploy.sh

🚩Как работает GitLab Runner

🟠Запуск задания: Когда код попадает в репозиторий (например, при пуше или создании мержа), GitLab инициирует запуск пайплайна, используя задания, определенные в .gitlab-ci.yml.
🟠Получение задания: Зарегистрированный Runner получает задание от GitLab сервера. Runner выбирается на основе меток и доступности.
🟠Выполнение задания: Runner выполняет шаги, указанные в скрипте задания (script). Это может включать сборку, тестирование, деплой и другие задачи.
🟠Отправка результатов: После выполнения задания Runner отправляет результаты обратно в GitLab сервер. Это включает в себя выходные данные, статусы выполнения и артефакты.

🚩Типы Executor-ов

🟠Shell: Выполнение команд в оболочке (например, Bash).
🟠Docker: Выполнение команд в Docker-контейнере.
🟠Docker+machine: Автоматическое создание Docker-окружений с использованием Docker Machine.
🟠Kubernetes: Выполнение заданий в подах Kubernetes.

В файле .gitlab-ci.yml можно указать Docker Executor для выполнения заданий в контейнерах:

build_job:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myapp:latest .
    - docker push myregistry/myapp:latest

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

🤔 Что такое Kubernetes — Open Standards (OCI, CRI, CNI, CSI, SMI, CPI)?

Kubernetes активно использует стандарты с открытым исходным кодом для обеспечения совместимости и расширяемости. Основные из них включают OCI, CRI, CNI, CSI, SMI и CPI. Эти стандарты определяют интерфейсы и протоколы, которые позволяют Kubernetes взаимодействовать с различными компонентами и инструментами.

🚩OCI (Open Container Initiative)

Проект Linux Foundation, который определяет стандарты для контейнеров. Основные спецификации OCI:
🟠OCI Image Format: Стандартный формат для контейнерных образов.
🟠OCI Runtime: Стандарт для выполнения контейнеров.

Kubernetes использует OCI-совместимые образы и среды выполнения, такие как runc, для обеспечения универсальной совместимости контейнеров.

🚩CRI (Container Runtime Interface)

Это интерфейс, который позволяет Kubernetes взаимодействовать с различными средами выполнения контейнеров. CRI определяет набор API, через которые kubelet может запускать и управлять контейнерами.
🟠containerd
🟠CRI-O
🟠Docker (через dockershim, который вскоре будет удален)

🚩CNI (Container Network Interface)

Это стандарт для настройки сетевых интерфейсов контейнеров и управления их жизненным циклом. CNI обеспечивает гибкость и расширяемость сетевых решений в Kubernetes.
🟠Calico
🟠Flannel
🟠Weave
🟠Cilium

🚩CSI (Container Storage Interface)

Это стандарт, который позволяет Kubernetes взаимодействовать с различными системами хранения данных. CSI определяет API для создания, удаления, монтирования и управления томами.
🟠Ceph
🟠 Amazon EBS
🟠Google Persistent Disk
🟠Azure Disk

🚩SMI (Service Mesh Interface)

Стандартный интерфейс для управления сервисными сетями (service mesh) в Kubernetes. SMI предоставляет набор абстракций для таких функций, как маршрутизация, телеметрия и управление трафиком.
🟠Istio
🟠Linkerd
🟠Consul Connect

🚩CPI (Cloud Provider Interface)

Интерфейс, который позволяет Kubernetes взаимодействовать с различными облачными провайдерами. CPI управляет ресурсами облака, такими как виртуальные машины, сети и хранилища, в контексте Kubernetes-кластера.
🟠AWS
🟠Google Cloud
🟠Microsoft Azure
🟠OpenStack

🚩Применение стандартов в Kubernetes

🟠Совместимость и расширяемость: Использование открытых стандартов обеспечивает совместимость между различными компонентами и упрощает интеграцию новых технологий.
🟠Упрощение управления: Стандарты, такие как CRI, CNI и CSI, упрощают управление контейнерами, сетями и хранилищами, предоставляя единообразные интерфейсы и API.
🟠Масштабируемость и гибкость: Открытые стандарты позволяют Kubernetes легко адаптироваться к различным средам и требованиям, обеспечивая гибкость и масштабируемость приложений.

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

🤔 Какие коды сообщений или ошибок HTTP знаешь и что это значит?

🚩HTTP коды статуса — это трехзначные числовые коды, которые сервер возвращает клиенту в ответ на HTTP запрос. Эти коды указывают на статус обработки запроса и помогают клиенту понять результат выполнения запроса. Коды делятся на пять категорий:

🟠1xx: Информационные коды
- 100 Continue: Сервер получил начальную часть запроса и клиент может продолжать отправку запроса.
- 101 Switching Protocols: Сервер переключается на другой протокол, указанный в заголовке Upgrade.

🟠2xx: Коды успешного выполнения
- 200 OK: Запрос выполнен успешно. Наиболее распространенный код для успешных запросов.
- 201 Created: Запрос успешно выполнен и приведен к созданию ресурса. Используется, например, при отправке данных на сервер для создания новой записи.
- 202 Accepted: Запрос принят для обработки, но обработка еще не завершена.
- 204 No Content: Запрос выполнен успешно, но тело ответа пусто.

🟠3xx: Коды перенаправления
- 301 Moved Permanently: Ресурс был перемещен на новый постоянный URL. Клиент должен использовать новый URL для будущих запросов.
- 302 Found: Ресурс временно доступен по другому URL. Клиент должен использовать оригинальный URL для будущих запросов.
- 304 Not Modified: Ресурс не был изменен с момента последнего запроса. Клиент может использовать кэшированную версию.

🟠4xx: Коды ошибок клиента
- 400 Bad Request: Сервер не может обработать запрос из-за ошибки клиента (например, неверный синтаксис запроса).
- 401 Unauthorized: Запрос требует аутентификации. Клиент должен предоставить учетные данные для доступа к ресурсу.
- 403 Forbidden: Сервер понял запрос, но отказывается его выполнять. Клиент не имеет необходимых прав для доступа к ресурсу.
- 404 Not Found: Ресурс не найден. Сервер не может найти запрошенный ресурс.
- 405 Method Not Allowed: Метод, указанный в запросе, не поддерживается для данного ресурса.
- 409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.
- 429 Too Many Requests: Клиент отправил слишком много запросов за короткий период. Используется для ограничения скорости запросов.

🟠5xx: Коды ошибок сервера
- 500 Internal Server Error: Общая ошибка сервера. Сервер столкнулся с неожиданной ситуацией, которая помешала выполнению запроса.
- 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
- 502 Bad Gateway: Сервер, выступающий в роли шлюза или прокси, получил недопустимый ответ от вышестоящего сервера.
- 503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания.
- 504 Gateway Timeout: Сервер, выступающий в роли шлюза или прокси, не получил своевременный ответ от вышестоящего сервера.

1: 200 OK

GET /index.html HTTP/1.1
Host: www.example.com

```http
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head><title>Example</title></head>
<body>Example page</body>
</html>

2: 404 Not Found

http
GET /nonexistent.html HTTP/1.1
Host: www.example.com

http
HTTP/1.1 404 Not Found
Content-Type: text/html
<html>
<head><title>404 Not Found</title></head>
<body>Page not found</body>
</html>`


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

🤔 Что есть Docker, а что Docker daemon?

💬 Спрашивают в 13% собеседований

🚩Что такое Docker

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

Основные компоненты Docker
🟠Docker Engine: Основной компонент Docker, включающий Docker daemon, CLI и API.
🟠Контейнеры: Легковесные и портативные окружения, содержащие все необходимое для запуска приложения.
🟠Образы (Images): Шаблоны для создания контейнеров, включающие файловую систему и настройки для запуска приложения.
🟠Docker Hub: Регистратор Docker-образов, где можно хранить и распространять образы.

Docker daemon (dockerd) — это основной процесс Docker, который управляет контейнерами, образами, сетями и хранилищами. Docker daemon отвечает за выполнение команд, отправляемых через Docker CLI или API, и контролирует все операции, связанные с контейнерами.

Основные функции Docker daemon

🟠Управление контейнерами:
- Создание, запуск, остановка, перезапуск и удаление контейнеров.
- Мониторинг состояния контейнеров и их взаимодействия с хостовой системой.

🟠Управление образами:
- Загрузка, создание, тегирование и удаление Docker-образов.
- Кэширование слоев образов для оптимизации повторного использования.

🟠 Управление сетями:
- Создание и управление виртуальными сетями для контейнеров.
- Поддержка различных сетевых драйверов (bridge, host, overlay и т.д.).

🟠Управление хранилищами:
- Создание и управление томами (volumes) для постоянного хранения данных контейнеров.

🚩Как работает Docker daemon

Docker daemon работает в фоновом режиме и взаимодействует с Docker CLI и API для выполнения команд. Когда пользователь вводит команду через Docker CLI (например, docker run), CLI отправляет эту команду Docker daemon через API. Docker daemon обрабатывает команду, выполняет необходимые действия и возвращает результат через CLI.

🟠Команда запуска контейнера: Пользователь вводит команду docker run hello-world в терминале.
🟠Docker CLI: Docker CLI отправляет запрос на запуск контейнера Docker daemon через API.
🟠Docker daemon: Docker daemon проверяет локальное наличие образа hello-world. Если образ отсутствует, он загружает его из Docker Hub.
🟠Docker daemon создает и запускает контейнер на основе образа hello-world.
🟠Docker daemon возвращает результат выполнения команды Docker CLI.

Результат: Пользователь видит вывод в терминале, подтверждающий успешный запуск контейнера.

$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

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

🤔 Чем отличается процесс от потока?

В современных операционных системах процессы и потоки (threads) являются основными единицами выполнения. Хотя они имеют много общего, есть несколько ключевых различий, которые определяют их использование и поведение.

Процесс — это экземпляр программы, который выполняется в операционной системе. Процессы имеют свои собственные ресурсы и память.

🚩Основные характеристики процесса:

🟠Изоляция: Каждый процесс имеет свое собственное адресное пространство и ресурсы (файлы, память).
🟠Контекст выполнения: Процесс имеет свой собственный контекст выполнения, включая регистры процессора, виртуальную память и дескрипторы файлов.
🟠Создание процессов: Создание нового процесса (например, с помощью системного вызова fork в Unix-подобных системах) занимает больше времени и ресурсов по сравнению с созданием потоков.
🟠Межпроцессное взаимодействие (IPC): Для обмена данными между процессами требуются механизмы IPC.

Поток (thread) — это более легковесная единица выполнения, которая существует внутри процесса. Потоки одного и того же процесса разделяют его ресурсы и память, что позволяет им эффективно взаимодействовать.

🚩Основные характеристики потока:

🟠Разделение ресурсов: Потоки одного процесса разделяют одно адресное пространство и ресурсы, такие как открытые файлы и память.
🟠Контекст выполнения: Каждый поток имеет свой собственный контекст выполнения, включая регистры процессора и стек, но разделяет память с другими потоками процесса.
🟠Создание потоков: Создание нового потока (например, с помощью pthread_create в POSIX-системах) быстрее и требует меньше ресурсов по сравнению с созданием нового процесса.
🟠Синхронизация: Потоки часто используют примитивы синхронизации, такие как мьютексы (mutexes), семафоры (semaphores) и условные переменные (condition variables) для координации доступа к общим ресурсам.

🚩Сравнение процессов и потоков

Память и ресурсы:
🟠Процессы: Изолированы друг от друга, имеют собственное адресное пространство и ресурсы.
🟠Потоки: Разделяют адресное пространство и ресурсы процесса.

Создание и управление:
🟠Процессы: Создание и управление процессами более затратное по времени и ресурсам.
🟠Потоки: Создание и управление потоками быстрее и менее затратное.

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

Пример создания процесса (на C с использованием fork):

#include <stdio.h>
#include <unistd.h>
int main() {
    pid_t pid = fork();
    if (pid == 0) {
        printf("Это дочерний процесс\n");
    } else if (pid > 0) {
        printf("Это родительский процесс\n");
    } else {
        perror("fork");
        return 1;
    }
    return 0;
}

Пример создания потока (на C с использованием pthreads):

#include <stdio.h>
#include <pthread.h>
void* thread_function(void* arg) {
    printf("Это поток\n");
    return NULL;
}
int main() {
    pthread_t thread;
    pthread_create(&thread, NULL, thread_function, NULL);
    pthread_join(thread, NULL);
    printf("Главный поток\n");
    return 0;
}

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

🤔 Почему сейчас 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

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