Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
#Круги добра
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр «Дурак подкидной и переводной» — классика карточных игр! Яркий геймплей, простые правила. Развивайте стратегию, бросайте вызов соперникам и станьте королем карт! Играйте прямо сейчас!

Дурак подкидной и переводной

Карточные, Настольные, Логическая

Играть

Топ прошлой недели

  • SpongeGod SpongeGod 1 пост
  • Uncleyogurt007 Uncleyogurt007 9 постов
  • ZaTaS ZaTaS 3 поста
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

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

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
0 просмотренных постов скрыто
Stravnik
Stravnik
1 год назад
Лига Сисадминов

Сохранение и загрузка нескольких Docker образов⁠⁠

Исходный код представленный в этой заметке доступен в моем репозитории GitHub.

Код скрипта для сохранения (save-images.sh):

#!/bin/bash

list="images.txt"

images="images.tar.gz"

usage() {

echo "USAGE: $0 [--image-list images.txt] [--images images.tar.gz]"

echo " [-l|--image-list path] text file with list of images; one image per line."

echo " [-i|--images path] tar.gz generated by docker save."

echo " [-h|--help] Usage message"

}

POSITIONAL=()

while [[ $# -gt 0 ]]; do

key="$1"

case $key in

-i | --images)

images="$2"

shift # past argument

shift # past value

;;

-l | --image-list)

list="$2"

shift # past argument

shift # past value

;;

-h | --help)

help="true"

shift

;;

*)

usage

exit 1

;;

esac

done

if [[ $help ]]; then

usage

exit 0

fi

pulled=""

while IFS= read -r i; do

[ -z "${i}" ] && continue

if docker pull "${i}" >/dev/null 2>&1; then

echo "Image pull success: ${i}"

pulled="${pulled} ${i}"

else

if docker inspect "${i}" >/dev/null 2>&1; then

pulled="${pulled} ${i}"

else

echo "Image pull failed: ${i}"

fi

fi

done <"${list}"

echo "Creating ${images} with $(echo ${pulled} | wc -w | tr -d '[:space:]') images"

docker save $(echo ${pulled}) | gzip --stdout >${images}

Код для загрузки (load-images.sh):

#!/bin/bash

images="images.tar.gz"

list="images.txt"

windows_image_list=""

windows_versions="1809"

usage() {

echo "USAGE: $0 [--images images.tar.gz] --registry my.registry.com:5000"

echo " [-l|--image-list path] text file with list of images; one image per line."

echo " [-i|--images path] tar.gz generated by docker save."

echo " [-r|--registry registry:port] target private registry:port."

echo " [--windows-image-list path] text file with list of images used in Windows. Windows image mirroring is skipped when this is empty"

echo " [--windows-versions version] Comma separated Windows versions. e.g., \"1809,2004,20H2\". (Default \"1809\")"

echo " [-h|--help] Usage message"

}

push_manifest() {

export DOCKER_CLI_EXPERIMENTAL=enabled

manifest_list=()

for i in "${arch_list[@]}"; do

manifest_list+=("$1-${i}")

done

echo "Preparing manifest $1, list[${arch_list[@]}]"

docker manifest create "$1" "${manifest_list[@]}" --amend

docker manifest push "$1" --purge

}

while [[ $# -gt 0 ]]; do

key="$1"

case $key in

-r | --registry)

reg="$2"

shift # past argument

shift # past value

;;

-l | --image-list)

list="$2"

shift # past argument

shift # past value

;;

-i | --images)

images="$2"

shift # past argument

shift # past value

;;

--windows-image-list)

windows_image_list="$2"

shift # past argument

shift # past value

;;

--windows-versions)

windows_versions="$2"

shift # past argument

shift # past value

;;

-h | --help)

help="true"

shift

;;

*)

usage

exit 1

;;

esac

done

if [[ -z $reg ]]; then

usage

exit 1

fi

if [[ $help ]]; then

usage

exit 0

fi

docker load --input ${images}

linux_images=()

while IFS= read -r i; do

[ -z "${i}" ] && continue

linux_images+=("${i}")

done <"${list}"

arch_list=()

if [[ -n "${windows_image_list}" ]]; then

IFS=',' read -r -a versions <<<"$windows_versions"

for version in "${versions[@]}"; do

arch_list+=("windows-${version}")

done

windows_images=()

while IFS= read -r i; do

[ -z "${i}" ] && continue

windows_images+=("${i}")

done <"${windows_image_list}"

# use manifest to publish images only used in Windows

for i in "${windows_images[@]}"; do

if [[ ! " ${linux_images[@]}" =~ " ${i}" ]]; then

case $i in

*/*)

image_name="${reg}/${i}"

;;

*)

image_name="${reg}/${i}"

;;

esac

push_manifest "${image_name}"

fi

done

fi

arch_list+=("linux-amd64")

for i in "${linux_images[@]}"; do

[ -z "${i}" ] && continue

arch_suffix=""

use_manifest=false

if [[ (-n "${windows_image_list}") && " ${windows_images[@]}" =~ " ${i}" ]]; then

# use manifest to publish images when it is used both in Linux and Windows

use_manifest=true

arch_suffix="-linux-amd64"

fi

case $i in

*/*)

image_name="${reg}/${i}"

;;

*)

image_name="${reg}/${i}"

;;

esac

docker tag "${i}" "${image_name}${arch_suffix}"

docker push "${image_name}${arch_suffix}"

if $use_manifest; then

push_manifest "${image_name}"

fi

done

Пример списка образов (images.txt):

quay.io/prometheus/prometheus:v2.36.1

quay.io/prometheus/node-exporter:v1.3.1

grafana/grafana:9.0.3

Показать полностью
[моё] DevOps Docker Github Длиннопост Текст
9
5
egorgasay
egorgasay
1 год назад

Идеальное тестирование Golang кода⁠⁠

В современной разработке программного обеспечения тестирование кода с реальными зависимостями становятся все более важным. И в этом контексте библиотека dockerdb представляет собой ценный инструмент для разработчиков. В данной статье мы рассмотрим основные особенности и преимущества данной библиотеки.

Описание библиотеки:

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

Преимущества и особенности:

  1. Тестирование с реальными зависимостями: Библиотека "dockerdb" позволяет разработчикам проводить тестирование баз данных с реальными зависимостями, включая другие сервисы или компоненты системы. Это позволяет более точно смоделировать реальную среду и выявить потенциальные проблемы.

  2. Автоочистка контейнеров: После завершения тестирования, "dockerdb" автоматически очищает использованные контейнеры, освобождая ресурсы и предотвращая накопление мусора. Это повышает эффективность и удобство процесса тестирования.

  3. Гибкость и простота использования: Библиотека "dockerdb" предоставляет простой и гибкий интерфейс для развертывания и управления базами данных в контейнерах Docker. Она поддерживает различные СУБД, такие как MySQL, PostgreSQL, MongoDB и другие.

Идеальное тестирование Golang кода Golang, Docker, Длиннопост

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

Идеальное тестирование Golang кода Golang, Docker, Длиннопост

Заключение:

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

Попробовать:

https://github.com/egorgasay/dockerdb

Показать полностью 2
[моё] Golang Docker Длиннопост
0
310
EnumaElis
1 год назад
Лига Сисадминов

Как настроить домашний медиасервер⁠⁠

Хочу сделать оговорку: я не считаю это единственно верным способом сделать домашний медиасервер. Наверное похожее сделать проще через DLNA (но я не разбирался как это сделать), можно поставить Kodi и пользоваться своей медиатекой без танцев с бубном. Я попробую рассказать как я делаю личный медиасервер у себя.

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

Какие сервисы используются и их назначение:

  • OS любая, я отдаю предпочтение Debian. Без GUI, только консоль и SSH. Сделайте IP-адрес статическим (либо в процессе установки, либо после в файле /etc/network/interfaces, либо на своём роутере). После установки из-под root добавляем утилиты sudo, curl, cifs-utils (если файловое хранилище у вас на SMB), остальное по потребностям. Добавляем созданного при установке пользователя в группу sudo (а после установки докера и в группу docker): "usermod -aG sudo username", после чего рекомендую работать из-под этого пользователя.

  • Docker. Можно ставить руками: "sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin", а можно скриптом: https://docs.docker.com/engine/install/debian/#install-using....

  • Portainer. Удобный веб-интерфейс для управления контейнерами и compose-конфигами. Совершенно необязательная, но удобная вещь. Простая инструкция по установке: https://docs.portainer.io/start/install-ce/server/docker/lin...

Теперь важная ремарка: в текущих условиях, когда РКН блокирует одни ресурсы с одной стороны, а западные санкции и разработчики блокируют ресурсы с другой стороны -- практически никакой из нижеперечисленных сервисов не будет работать "из коробки", либо будет но криво-косо. Поэтому важной и необходимой частью системы будет VPN. Реализовывать маршрут нужных сервисов через VPN можно разными способами, я выбрал через клиента в контейнере.

  • Gluetun. https://github.com/qdm12/gluetun Умеет работать со многими провайдерами VPN, умеет работать с разными протоколами VPN и пр. Всё что требуется - прописать в конфигурации клиентские данные с вашего VPN-сервера, а затем пустить сетевой трафик другого контейнера через контейнер с gluetun. Делается это с помощью параметра network_mode: "service:gluetun". Обратите внимание, что проброс портов в контейнеры использующих этот режим, прописывается в разделе сервиса gluetun. А для внутренних коммуникаций между этими сервисами адрес указывайте как localhost (или 127.0.0.1, как удобнее).

Пример моего конфига: https://hastebin.com/share/cidejifuta.yaml

Важно: не пускайте трафик вашего торрент-клиента через VPN (см. мой предыдущий пост: Домашний сервер и неожиданная проблема) :)

Самое интересное:

  • Radarr. "Сердце" системы :) Это приложение, получая запросы пользователя на новый фильм, обращается к индексатору трекеров (Prowlarr или Jackett), откуда получает список раздач данного фильма по заданным вами критериям: качество и разрешение, минимальный-средний-максимальный размер файла, минимальное количество сидеров на раздаче и пр. Может автоматически отдать ссылку на .torrent-файл вашему торрент-клиенту, может ожидать вашего решения по самостоятельному ручному выбору раздачи из списка. Мониторит запрошенные скачивания в торрент-клиенте и увидев завершённую скачку, копирует этот файл к себе в организованную библиотеку, создавая папки и переименовывая по вашему шаблону.

  • Sonarr. Практически то же самое, но для сериалов. Да, для фильмов и сериалов два отдельных приложения :)

  • Prowlarr. Индексатор торрент-трекеров, обширный список известных и популярных. Получая с Radarr'a поисковый запрос с названием фильма, обращается к выбранным вами трекерам и возвращает список доступных раздач с описанием имени раздачи, количеством сидеров, размером файла и качеством раздаваемого фильма.

  • qBittorrent/Deluge. Торрент-клиент. После автоматического или ручного выбора требуемой раздачи, сюда прилетает .torrent-файл и клиент начинает скачивать требуемое.

  • Jellyfin. Медиасервер, которому мы скармливаем библиотеки фильмов и сериалов и который воспроизводит этот контент на любом устройстве. Есть клиенты подо все распространённые платформы, умеет транслировать видео в веб-браузер, т.е. можно обойтись без клиентского ПО. Может аппаратно, на лету, перекодировать фильм в требуемом клиенту разрешении. Кому-то эта функция может показаться сомнительной, но мне было удобно, уехав от дома за 200км на дачу к родственникам (где нет оптики и 20-30Мбит скорость это ещё шикарно), запустить 2к фильм запросив его пережать в 720р. Альтернатива - Plex, но он вроде бы платный.

  • Jellyseerr. Опционально. Мне не очень понравился. Задуман как простой сервис запросов пользователей на фильмы. Выбираешь кино из списка в тренде, либо через поиск, либо рекомендованным (предварительно скормив в настройках библиотеку своего Radarr) и выбранный фильм улетает запросом в Radarr и дальше по цепочке.

Как в итоге это всё работает? Я с любого места и с любого устройства (способного хотя бы 360р воспроизвести) могу подключиться и посмотреть любимый фильм/сериал без рекламы и тормозов. Если фильма нет в библиотеке, так же захожу на Radarr/Jellyseer, нахожу нужное кино и велю скачать его. Можно поставить галку и тогда закачка начнётся автоматически, по окончанию закачки мне в телеграм прилетит уведомление об этом.

Показать полностью
Linux Docker Домашний кинотеатр VPN Текст
267
108
tproger.official
tproger.official
1 год назад
Типичный программист

Держите детей подальше от k8ts⁠⁠

Держите детей подальше от k8ts
IT IT юмор Программирование Docker Скриншот Сарказм
18
1
ritd
2 года назад

Перестал запускаться minikube⁠⁠

Доброго дня! Может кто уже сталкивался и как то решил. Зависает запуск minikube

Перестал запускаться minikube Kubernetes, Docker, IT, Программирование, Нужен совет
[моё] Kubernetes Docker IT Программирование Нужен совет
1
2
soaqa
soaqa
2 года назад
Лига программистов

ГОТОВИМ DOCKERFILE ДОМА⁠⁠

Привет! Прошлый ролик по докеру не зашёл, а залетел просто! Комментарии просто взорвались, как и моя пятая точка от некоторых из них)))

И я решил снять продолжение! Надеюсь вам понравится!

[моё] YouTube Программирование Python IT Docker Видео Linux
3
1465
soaqa
soaqa
2 года назад
Лига программистов

DOCKER БЫТОВОЙ УРОВЕНЬ⁠⁠

Привет! Это небольшой гайд для новичков в Docker, который должен помочь тебе начать пользоваться докером!

[моё] Программирование Docker Linux IT Видео YouTube
290
6
gogobugogo
gogobugogo
2 года назад
Site Reliability Engineering
Серия SRE

Как создавать софт, как SRE⁠⁠

Перевод очень интересной статьи "How to Build Software like an SRE", в которой разбираются подходы к созданию приложений с точки зрения SRE.

Принципы надежности и компромиссы, усвоенные на собственном горьком опыте

Я занимаюсь этой “надежностью” уже некоторое время (около 5 лет), в компаниях, насчитывающих от 20 до более чем 2000 человек. Меня всегда в первую очередь всегда интересовали те элементы ПО, которые я описываю как живущие “вне” приложения — например, как приложение получает свою конфигурацию? На каких типах серверов оно запускается и являются ли эти типы наиболее подходящими? Что с ним происходит на пути от “кода в репозитории” до “запуска на проде”? И я всегда следил за тем, что мне нравится — какие механизмы позволяют быструю итерацию, а какие вызывают разочарование, какие приводят к сбоям, а какие предотвращают их.

Я думаю, что будет полезно, если я все это запишу, даже если это будет просто для меня в качестве справочника.

Обратите внимание, что этот список немного странный с точки зрения SRE. Моя цель не заключается в том, чтобы “построить все так, чтобы надежность была 100%”; это больше похоже на “как достичь 80% надежности, затратив 20% усилий, при этом позволяя разработчикам работать быстро”, что в конечном итоге дает нам систему, которая выглядит совсем по-другому. Но это стоит попробовать — если делать это хорошо, работа с продом становится интересной, а не уныло безопасной или ужасающе опасной.

Также, пожалуйста, сделайте мне одолжение и мысленно дополните каждый из следующих пунктов словом “обычно”. Каждая ситуация уникальна, и то, что я не сталкивался с тем, что (например) использование Git является плохой идеей, не означает, что такого случая не существует. “Только Ситхи всё возводят в абсолют”, и т.д.

Итак! Пройдя через всё это — вот как я бы начал все сначала, если бы мог.

Coding (параметры? да я их еле знаю!)

Никаких конфигов, зашитых в код. Если ваш сервис по какой-либо причине не может загрузить конфигурацию при запуске, он должен просто аварийно завершиться — этот случай гораздо проще диагностировать, чем результат того, что инстанс выполнил старый код, потому что никто не вспомнил о том, что нужно удалить строку config.get(enable_cool_new_thing, false).

Чрезвычайно строгие настройки RPC. Я говорю о нуле (или МОЖЕТ БЫТЬ одной) повторных попыток и таймауте, в 3 раза превышающем p⁹⁹. Здесь мы стремимся к предсказуемости, и многократные повторные попытки или длительные таймауты в качестве быстрого решения проблемы в работе сервиса превратятся в недельное расследование и головную боль через год. Исправьте неисправный сервис!

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

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

Merging (там, куда мы идем — тесты не нужны)

Используйте Git. Используйте его для всего — инфраструктуры, конфигов, кода, дашбордов, графиков дежурств. Ваш репозиторий Git — это источник истины, который можно восстановить на определенный момент времени.

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

Уделяйте приоритетное внимание тестам в реальных условиях. Самый ценный тест, который занимает меньше всего времени, — это просто применение вашего изменения на стейджинге (или, еще лучше, на проде!) и демонстрация того, что оно делает то, что вы хотели, и не ломает всё. На втором месте по эффективности находятся интеграционные тесты, а юнит-тесты идут последними — то есть, “только если у вас есть на них время”.

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

При внесении изменений в код делайте регрессии максимально очевидными. Журналы ошибок, использование ЦП и частота ошибочных запросов являются отличными сигналами, позволяющими выявить около 90% плохих версий и работают для практически любого сервиса (полностью универсальны). Так что не отбрасывайте их!

Deploying (no sleep til prod)

Используйте Docker. Это отраслевой стандарт не просто так — разбор зависимостей в средах с такими инструментами, как Chef или Ansible, всегда проигрывает этой приятной автономности.

Развертывайте всё и всегда. Каждый день, который проходит без вашего деплоя, увеличивает вероятность того, что он на самом деле был незаметно сломан (в результате чьего-то изменения, обновления зависимостей, удаления стороннего API), и через две недели будет очень трудно выяснить, что и где пошло не так.

Проверяйте развертывания по мере их выполнения. Можете ли вы создать полностью поврежденный образ и успешно разлить его на все машины? Почему? Это можно исправить несколькими способами, включая canary/shadow развертывания или даже просто хорошими readiness проверками.

Включите ограничение на “мгновенное” развертывание конфигов. Это может показаться нелогичным (“мгновенное” часто означает “сломать все сразу и быстро”), но возможность отключить проблемную функцию или заблокировать IP менее чем за 5 минут с лихвой компенсирует повышенный риск. Это позволяет всё делать быстро, но управлять этим нужно осторожно!

Operating (my god, it’s full of pods)

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

Используйте Helm. Или какой-то другой инструмент для управления манифестами Kubernetes, я не привередлив — главное, чтобы вы никогда не использовали прямые команды kubectl apply, edit или delete. Жизненный цикл ресурсов должен быть доступен в системе контроля версий.

Избегайте операторов и CRD (Custom Resource Definition). Как уже упоминалось выше, я люблю Kubernetes, но для очень многих разработчиков он очень сложен, и пользовательские операторы резко уходят в область “Что это за херня?”, что создает ему сложную репутацию. Пусть все будет просто.

Запускайте по 3 экземпляра всего. Как и с резервными копиями, два экземпляра — это один, а один — не существует :) Кроме того, убедитесь (действительно проверьте на проде), что 2 из 3 “штук” могут справиться с полной нагрузкой самостоятельно — в противном случае у вас на самом деле нет такой устойчивости к сбоям, как вы думаете.

Структурированные логи — это неотъемлемая часть. Вместе с идентификаторами трассировки они позволяют вам пройти 90% пути к APM (application performance monitoring), но при гораздо меньших затратах и усилиях со стороны разработчиков.

Итак, это текущий список! Думаю, что буду периодически возвращаться сюда и добавлять что-то еще. Пожалуйста, не стесняйтесь обращаться ко мне, если что-то из этого особенно вас раздражает или если у вас есть ещё что-то, о чем бы вы хотели бы поговорить 😜

Показать полностью
[моё] Sre IT Kubernetes Docker Разработка Программирование Длиннопост Текст
0
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии