Расскажите о балансировщиках нагрузки в Kubernetes.
В Kubernetes балансировщик нагрузки — это компонент, который распределяет входящий сетевой трафик между несколькими экземплярами приложения, работающего в кластере. Балансировщик нагрузки отправляет подключения к одному серверу в пуле на основе алгоритма определения следующего сервера и отправляет новые подключения к следующему доступному серверу. Этот алгоритм идеален там, где виртуальные машины требуют значимых затрат, например в размещенных средах. Некоторые из стратегий, используемых для балансировки нагрузки, — это циклический перебор, бесконечность сеансов и хеширование IP.
Bind mount: подключаются к любой точке файловой системы сервера; Volume mount: управляются Docker и хранятся как часть файловой системы сервера; tmpfs mount: хранятся в оперативной памяти сервера, поэтому никогда не пишутся на реальную файловую систему сервера.
Расскажите о командах systemd для управления Docker
Для запуска Docker многие дистрибутивы Linux используют systemd. Для запуска сервисов используется команда systemctl. Если ее нет, следует использовать команду service.
$ sudo systemctl start docker $ sudo service docker start
Чтобы добавить сервис в автозагрузку, либо убрать его:
docker -version: узнать установленную версию Docker; docker ps: перечислить все запущенные контейнеры вместе с дополнительной информацией о них; docker ps -a: перечислить все контейнеры, включая остановленные, вместе с дополнительной информацией о них; docker exec: войти в контейнер и выполнить в нем команду; docker build: собрать образ из Dockerfile; docker rm: удалить контейнер с указанным идентификатором; docker rmi: удалить образ с указанным идентификатором; docker info: получить расширенную информацию об установленном Docker, например, сколько запущено контейнеров, образов, версию ядра, доступную оперативную память и т.п.; docker cp: сохранить файл из контейнера в локальную систему; docker history: показать историю образа с указанным именем.
🐰 Как решить проблему высокой связанности сервисов с помощью событийно-ориентированной архитектуры и RabbitMQ
В этой статье я расскажу, как оптимизировать сложную систему микросервисов через брокер сообщений, в данном случае RabbitMQ. Мы рассмотрим вариант решения проблемы высокой связанности между сервисами через переход на событийно-ориентированную архитектуру (EDA).
Под объектами понимают образы, сервисы и контейнеры. Образы — шаблоны с инструкциями только для чтения для создания контейнеров. Контейнеры — запущенные экземпляры образов. Сервисы — можно запустить несколько контейнеров поверх нескольких сервисов Docker, работающих совместно как swarm.
В момент появления понятия виртуализации, оно представляло собой метод логического разделения мейнфреймов для одновременной работы нескольких приложений. Однако с развитием технологий появилась возможность одновременной работы нескольких операционных систем на одном сервере x86, что значительно изменило смысл виртуализации.
В результате виртуализация позволяет запускать две различные операционные системы на одном устройстве. Первая операционная система может использоваться для административных целей, в то время как остальные гостевые операционные системы загружаются как обычно, включая инициализацию и загрузку ядра. Этот метод также обеспечивает повышенный уровень безопасности, так как гостевая операционная система не имеет полного доступа к управляющей (host) операционной системе, что помогает избежать возможных уязвимостей в безопасности.
Есть три типа виртуализации: ✍🏻 Паравиртуализация ✍🏻 Эмуляция ✍🏻 Контейнерная виртуализация
Приведите необходимые шаги для развертывания докеризированного приложения, сохраненного в репозитории Git
Шаги, необходимые для развертывания приложения зависят от окружения, основной процесс развертывания будет таким:
✍🏻 Сборка приложения с использованием Docker build в каталоге с кодом приложения ✍🏻 Тестирование образа ✍🏻 Выгрузка образа в Registry ✍🏻 Уведомление удаленного сервера приложений, что он может скачать образ из Registry и запустить его ✍🏻 Перестановка порта в прокси HTTP(S) ✍🏻 Остановка старого контейнера
bridge, сеть, к которой подключаются контейнеры, если не указано иначе. none, сетевой стек без наличия сетевого интерфейса в контейнере. host, подключение к сетевому стеку сервера.
✍🏻 build, сборка образа для Docker ✍🏻 create, создание нового контейнера ✍🏻 kill. принудительная остановка контейнера ✍🏻 dockerd, запуск сервиса Docker ✍🏻 commit, создание нового образа из изменений в контейнере
Основные составные части архитектуры Docker — это:
✍🏻 сервер, содержит сервис Docker, образы и контейнеры. Сервис связывается с Registry, образы — метаданные приложений, запускаемых в контейнерах Docker. ✍🏻 клиент, применяется для запуска различных действий на сервере Docker. ✍🏻 registry, используется для хранения образов. Есть публичные, доступные каждому, например, Docker Hub и Docker Cloud.
Docker Registry используется для сохранения образов Docker. Существует два общедоступных сервиса хранения: Docker Hub и Docker Cloud. Docker Hub является наиболее важной общедоступной системой хранения образов контейнеров, которую полностью поддерживают многие разработчики и другие участники сообщества.
Основное различие между этими двумя командами заключается в том, что вторая создаст контейнер в остановленном состоянии. Кроме того, docker create может быть использована для сохранения и вывода идентификатора контейнера для последующего использования. Рекомендуется использовать docker run с опцией --cidfile FILENAME, чтобы избежать перезаписи файла при повторном запуске.
CNM или Container Network Model — описание, формально определяющее шаги, требуемые для предоставления сети контейнерам, где обслуживающая абстракция применяется для поддержки нескольких сетевых драйверов. CNM основан на трех компонентах: sandbox (песочница), оконечная точка и сеть.
