Когда вы автоматизируете какую-либо задачу, например, упаковываете свое приложение для Docker, то часто сталкиваетесь с написанием shell-скриптов. У вас может быть bash-скрипт для управления процессом упаковки и другой скрипт в качестве точки входа в контейнер. По мере возрастающей сложности при упаковке меняется и ваш shell-скрипт.
Все работает хорошо.
Изображение Hessel Visser с сайта Pixabay
Поддержание образов в актуальном состоянии является стандартной процедурой при эксплуатации и управлении контейнерной средой. Далее мы рассмотрим, как следует это делать.
Podman — это daemon-less движок для разработки, управления и запуска контейнеров, соответствующих Open Container Initiative (OCI). Это одна из серии статей об использовании Podman, основанная на том, что я делаю в своей реальной рабочей среде. Ранее я показывал, как отображать сетевую информацию с помощью Podman, включая контейнеры и IP-адреса подов.
В данной же статье показано, как обновлять образы контейнеров. Очень важно поддерживать запущенные контейнеры и поды в актуальном состоянии с самыми последними обновлениями образа. Прежде чем следовать этой статье, вы можете сначала запустить shell-скрипты, которые я использовал в одной из предыдущих статей, в разделе "Первичная настройка".
Читать полностью »
Старайтесь всегда использовать многоэтапную сборку, для создания более компактных Docker образов. Давайте, рассмотрим на примере, как многоэтапная сборка позволяет значительно уменьшить размер Docker образа. В качестве примера, мы будем использовать простое веб-приложение на Golang:
package main
import (
"fmt"
"log"
"net/http"
)
func main() {
http.HandleFunc("/", HelloServer)
fmt.Printf("Starting server at port 8080n")
if err := http.ListenAndServe(":8080", nil); err != nil {
log.Fatal(err)
}
}
func HelloServer(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello world")
}
Сначала, соберем Docker образ в один этап:
Читать полностью »
Все, кто хоть раз в жизни, по работе открывал файл /etc/services знают, что одни сетевые службы используют транспортный протокол TCP, другие же — UDP. Каждый из них имеет свою область применения. Если надёжность соединения имеет приоритет над скоростью передачи данных, то TCP предпочтительнее. Например, для SMTP, или IMAP больше подходит TCP. Обратное тоже верно там, где важна скорость передачи данных, а потеря дейтаграмм или их порядок не критичны — используют UDP. К их числу относятся SNMP, DNS, VoIP и другие службы.Читать полностью »
В этой статье мы рассмотрим, как с помощью Open Source-утилиты werf собрать Docker-образ простейшего приложения и развернуть его в кластере Kubernetes, а также с легкостью накатывать изменения в его коде и инфраструктуре.
Недавно компания Datadog, разработчик одноименной системы мониторинга, представила свой обновленный отчет «10 трендов использования контейнеров в реальном мире». Авторы исследования проанализировали полтора миллиарда контейнеров, развернутых тысячами компаниями-клиентами Datadog.
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
Трудно представить современную разработку без контейнеризации. Docker и Kubernetes прочно обосновались на рынке, и, если вы ещё не знакомы с этими технологиями, им явно стоит уделить внимание.
Запуск баз данных и других stateful приложений в контейнере – это тема интересная, но способная вызвать очередной Большой взрыв в комментариях. Оговорюсь сразу, мы не используем в production окружении PostgreSQL в Docker. Но делаем это в локальной разработке и на dev-стендах. Почему? Потому что это чертовски удобно!
