Еще парочка ограничений уже от компании Docker (с 1 ноября 2020) касаются больше бесплатного тарифа:
- Хранение образов основано на активности скачивания или закачивания каждого отдельного образа, сохраненного с использованием учетной записи пользователя. Если образ не скачивался/закачивался в течение 6 месяцев, он получит метку «неактивный», они в свою очередь будут хранится 6 месяцев.
- Ограничения на скачивание образов Docker основаны на типе учетной записи пользователя, запрашивающего образ (200 запросов за 6 часов с одного ID). Неавторизованные загрузки являются «анонимными» и ограничиваются по IP-адресу вместо пользовательского ID (100 запросов за 6 часов с одного адреса).
Вот коротко о том что изменится.
Еще раз убеждаюсь что для безопасной и стабильной разработки надо делать в компании свой docker registry.
#docker
- Хранение образов основано на активности скачивания или закачивания каждого отдельного образа, сохраненного с использованием учетной записи пользователя. Если образ не скачивался/закачивался в течение 6 месяцев, он получит метку «неактивный», они в свою очередь будут хранится 6 месяцев.
- Ограничения на скачивание образов Docker основаны на типе учетной записи пользователя, запрашивающего образ (200 запросов за 6 часов с одного ID). Неавторизованные загрузки являются «анонимными» и ограничиваются по IP-адресу вместо пользовательского ID (100 запросов за 6 часов с одного адреса).
Вот коротко о том что изменится.
Еще раз убеждаюсь что для безопасной и стабильной разработки надо делать в компании свой docker registry.
#docker
UFW - это популярный интерфейс iptables в Ubuntu, упрощающий управление правилами брандмауэра. Но Docker обходит правила UFW и опубликованные порты могут быть доступны извне. Как обычно происходит:
1. UFW включен и все входящие соединения, которые не разрешены, по умолчанию блокируются.
2. Запускаем контейнер Docker на сервере, используя параметр -p, чтобы опубликовать порты для этого контейнера на всех IP-адресах. Например: docker run -d --name httpd -p 0.0.0.0:8080:80 httpd: alpine, эта команда запустит службу httpd и опубликует порт 80 контейнера на порту 8080 сервера.
3. UFW не будет блокировать все внешние запросы на посещение порта 8080. Даже команда ufw deny 8080 не будет препятствовать внешнему доступу к этому порту. Получается порт, который изначально должен был быть доступен только внутри подсети, оказался доступен публичной сети.
Как я обошел это ограничение описал в своем github: https://github.com/il-da-r/dockerufw
#docker
1. UFW включен и все входящие соединения, которые не разрешены, по умолчанию блокируются.
2. Запускаем контейнер Docker на сервере, используя параметр -p, чтобы опубликовать порты для этого контейнера на всех IP-адресах. Например: docker run -d --name httpd -p 0.0.0.0:8080:80 httpd: alpine, эта команда запустит службу httpd и опубликует порт 80 контейнера на порту 8080 сервера.
3. UFW не будет блокировать все внешние запросы на посещение порта 8080. Даже команда ufw deny 8080 не будет препятствовать внешнему доступу к этому порту. Получается порт, который изначально должен был быть доступен только внутри подсети, оказался доступен публичной сети.
Как я обошел это ограничение описал в своем github: https://github.com/il-da-r/dockerufw
#docker
GitHub
GitHub - il-da-r/dockerufw: Исправить ошибку безопасности Docker и UFW без отключения Iptables в Ubuntu
Исправить ошибку безопасности Docker и UFW без отключения Iptables в Ubuntu - il-da-r/dockerufw
Статья на Хабре где достаточно просто и понятно написано про хранение в docker: docker volumes, bind mount и tmpf.
#мануал по #docker
https://habr.com/ru/company/southbridge/blog/534334/
#мануал по #docker
https://habr.com/ru/company/southbridge/blog/534334/
Хабр
Хранение данных в Docker
Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но...
Недавно открыл для себя возможности BuildKit для сборки образов контейнеров.
Если не знакомы, то можно познакомится тут:
https://docs.docker.com/develop/develop-images/build_enhancements/
Субъективно скорость сборки образов увеличилась.
Есть еще пару интересных фич. BuildKit стоит за функцией мультиплатформенной сборки docker buildx и поддерживает возможность параллельного выполнения сборок несколькими рабочими процессами. BuildKit также поддерживает кеширование, различные внешние интерфейсы, более быстрые многоступенчатые сборки и т.п.
А надо то всего запустить:
DOCKER_BUILDKIT=1 docker build .
Или для docker-compose:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Захотелось понять как это работает. Наткнулся на статьи Адама Гордона Белла где он описывает прямую работу с Buildkit и сравнивает сборку докер образов с работой компилятора. Перевел их для вас. Если конечно хотите чуток углубится.
#docker #buildkit
https://habr.com/ru/post/550562/
Если не знакомы, то можно познакомится тут:
https://docs.docker.com/develop/develop-images/build_enhancements/
Субъективно скорость сборки образов увеличилась.
Есть еще пару интересных фич. BuildKit стоит за функцией мультиплатформенной сборки docker buildx и поддерживает возможность параллельного выполнения сборок несколькими рабочими процессами. BuildKit также поддерживает кеширование, различные внешние интерфейсы, более быстрые многоступенчатые сборки и т.п.
А надо то всего запустить:
DOCKER_BUILDKIT=1 docker build .
Или для docker-compose:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Захотелось понять как это работает. Наткнулся на статьи Адама Гордона Белла где он описывает прямую работу с Buildkit и сравнивает сборку докер образов с работой компилятора. Перевел их для вас. Если конечно хотите чуток углубится.
#docker #buildkit
https://habr.com/ru/post/550562/
You’re using docker-compose wrong
Такой заголовок я увидел в блоге Earthly. Мне стало интересно какие же "грехи" мы совершаем при использовании docker-compose. Сразу скажу писал разработчик, использующий docker-compose локально.
У нас осталось 4 будних дня. Вот и опишем по одному "греху" в день.
Грех 1. Использование сети хоста.
Некоторые разработчики грешат тем что используют не bridge driver, а host driver.
Использование сети хоста означает, что вам необходимо зарезервировать определенные порты для различных микросервисов, которые вы используете. Если вам доведется поднять два стека, которые имеют одинаковые порты - проблема. Если вы хотите создать две версии одного и того же стека - проблема. Вы хотите протестировать поведение определенного сервиса, когда у него несколько реплик?
По умолчанию docker-compose запускает свои контейнеры в отдельной сети с именем имякаталога_default. Так что на самом деле вам не нужно делать ничего особенного, чтобы воспользоваться преимуществами сетей Docker.
Эта сеть сразу дает вам ряд преимуществ:
🔸Эта сеть более изолирована от вашей сети хоста, поэтому маловероятно, что особенности вашего системного окружения приведут к изменению поведения настройки сборки. У вас есть доступ к Интернету, но любые порты, которые вы хотите сделать доступными с хоста, должны быть объявлены с привязкой порта.
Если служба начинает прослушивать 0.0.0.0 (как должны делать контейнеры), то настройка сети хоста откроет этот порт в вашей локальной сети. Если вы используете сеть Docker, она предоставит доступ только к этому порту.
🔸Сервисы смогут общаться, используя их имена в качестве имен хостов. Итак, если у вас есть служба с именем db и в ней есть служба, прослушивающая порт 5432, вы можете получить к ней доступ из любой другой службы через db: 5432. Обычно это более понятно, чем localhost: 5432. А поскольку нет риска конфликта портов localhost, у нас больше шансов избежать ошибок при использовании портов в разных проектах.
🔸Большинство портов не нужно открывать для хоста - это означает, что они не конкурируют за глобальные ресурсы, если вам нужно увеличить количество контейнеров с помощью --scale.
#docker
Такой заголовок я увидел в блоге Earthly. Мне стало интересно какие же "грехи" мы совершаем при использовании docker-compose. Сразу скажу писал разработчик, использующий docker-compose локально.
У нас осталось 4 будних дня. Вот и опишем по одному "греху" в день.
Грех 1. Использование сети хоста.
Некоторые разработчики грешат тем что используют не bridge driver, а host driver.
Использование сети хоста означает, что вам необходимо зарезервировать определенные порты для различных микросервисов, которые вы используете. Если вам доведется поднять два стека, которые имеют одинаковые порты - проблема. Если вы хотите создать две версии одного и того же стека - проблема. Вы хотите протестировать поведение определенного сервиса, когда у него несколько реплик?
По умолчанию docker-compose запускает свои контейнеры в отдельной сети с именем имякаталога_default. Так что на самом деле вам не нужно делать ничего особенного, чтобы воспользоваться преимуществами сетей Docker.
Эта сеть сразу дает вам ряд преимуществ:
🔸Эта сеть более изолирована от вашей сети хоста, поэтому маловероятно, что особенности вашего системного окружения приведут к изменению поведения настройки сборки. У вас есть доступ к Интернету, но любые порты, которые вы хотите сделать доступными с хоста, должны быть объявлены с привязкой порта.
Если служба начинает прослушивать 0.0.0.0 (как должны делать контейнеры), то настройка сети хоста откроет этот порт в вашей локальной сети. Если вы используете сеть Docker, она предоставит доступ только к этому порту.
🔸Сервисы смогут общаться, используя их имена в качестве имен хостов. Итак, если у вас есть служба с именем db и в ней есть служба, прослушивающая порт 5432, вы можете получить к ней доступ из любой другой службы через db: 5432. Обычно это более понятно, чем localhost: 5432. А поскольку нет риска конфликта портов localhost, у нас больше шансов избежать ошибок при использовании портов в разных проектах.
🔸Большинство портов не нужно открывать для хоста - это означает, что они не конкурируют за глобальные ресурсы, если вам нужно увеличить количество контейнеров с помощью --scale.
#docker
Грех 2. Вы привязываете порты к 0.0.0.0 хоста.
Привязка портов как 8080:8080. На первый взгляд это выглядит безобидно. Но дьявол кроется в деталях. Эта чрезвычайно распространенная привязка портов не просто перенаправляет порт контейнера на локальный хост - она перенаправляет его, чтобы он был доступен на каждом сетевом интерфейсе в вашей системе, включая все, что вы используете для подключения к Интернету.
Это означает, что очень вероятно, что ваши контейнеры разработки постоянно прослушивают вашу локальную сеть - когда вы дома, когда вы в офисе или когда вы находитесь в McDonald’s. Это всегда доступно. Это может быть опасно. Не делай этого.
«Но я использую ufw, мои порты по умолчанию недоступны».
Это может быть правдой, но если вы используете эту настройку docker-compose в команде, у одного из ваших товарищей по команде может не быть брандмауэра на своем ноутбуке.
Исправить очень просто: просто добавьте 127.0.0.1: впереди. Так, например, 127.0.0.1:8080:8080. Это просто указывает докеру, чтобы он открывал порт только для петлевого сетевого интерфейса и ничего больше.
#docker
Привязка портов как 8080:8080. На первый взгляд это выглядит безобидно. Но дьявол кроется в деталях. Эта чрезвычайно распространенная привязка портов не просто перенаправляет порт контейнера на локальный хост - она перенаправляет его, чтобы он был доступен на каждом сетевом интерфейсе в вашей системе, включая все, что вы используете для подключения к Интернету.
Это означает, что очень вероятно, что ваши контейнеры разработки постоянно прослушивают вашу локальную сеть - когда вы дома, когда вы в офисе или когда вы находитесь в McDonald’s. Это всегда доступно. Это может быть опасно. Не делай этого.
«Но я использую ufw, мои порты по умолчанию недоступны».
Это может быть правдой, но если вы используете эту настройку docker-compose в команде, у одного из ваших товарищей по команде может не быть брандмауэра на своем ноутбуке.
Исправить очень просто: просто добавьте 127.0.0.1: впереди. Так, например, 127.0.0.1:8080:8080. Это просто указывает докеру, чтобы он открывал порт только для петлевого сетевого интерфейса и ничего больше.
#docker
Грех 3. Вы используете healthy для координации запуска службы
Основная причина, по которой эта проблема такая важная, заключается в том, что Docker или Docker Compose не поддерживают ее. Версия 2.1 формата docker-compose имела параметр depends_on для которого можно было установить значение service_healthy. Кроме того, каждая служба может иметь команду проверки работоспособности, которая может сообщать docker-compose - healthy. Что ж этого больше нет в версии 3.0 и никакой замены для него не предлагается.
Документация Docker в основном рекомендует сделать ваш сервис устойчивым к отсутствию других сервисов, потому что это то, что в любом случае может произойти в производственной среде, например если будет прерывание сигнала сети или если сервис перезапустится. Не могу поспорить с этой логикой.
Это становится немного более обременительным когда вы запускаете интеграционный тест и процедуры, предназначенные для инициализации тестовой среды (например, предварительное заполнение базы данных некоторыми тестовыми данными) службы в конечном итоге могут не запуститься до того, как другая служба будет готова. Таким образом, аргумент о том, что «в любом случае он должен быть устойчивым в производственной среде», здесь не совсем применим, потому что код для заполнения БД тестовыми данными никогда не используется в производственной среде.
В таких случаях вам нужно что-то, что ждет готовности сервисов. Docker рекомендует использовать wait-for-it, Dockerize или wait-for. Однако обратите внимание, что готовность порта не всегда является признаком того, что служба готова к использованию. Например, в интеграционном тесте с использованием определенной базы данных SQL с определенной схемой порт становится доступным при инициализации базы данных, однако тест может работать только после применения определенной миграции схемы. Сверху могут потребоваться проверки для конкретного приложения.
#docker
Основная причина, по которой эта проблема такая важная, заключается в том, что Docker или Docker Compose не поддерживают ее. Версия 2.1 формата docker-compose имела параметр depends_on для которого можно было установить значение service_healthy. Кроме того, каждая служба может иметь команду проверки работоспособности, которая может сообщать docker-compose - healthy. Что ж этого больше нет в версии 3.0 и никакой замены для него не предлагается.
Документация Docker в основном рекомендует сделать ваш сервис устойчивым к отсутствию других сервисов, потому что это то, что в любом случае может произойти в производственной среде, например если будет прерывание сигнала сети или если сервис перезапустится. Не могу поспорить с этой логикой.
Это становится немного более обременительным когда вы запускаете интеграционный тест и процедуры, предназначенные для инициализации тестовой среды (например, предварительное заполнение базы данных некоторыми тестовыми данными) службы в конечном итоге могут не запуститься до того, как другая служба будет готова. Таким образом, аргумент о том, что «в любом случае он должен быть устойчивым в производственной среде», здесь не совсем применим, потому что код для заполнения БД тестовыми данными никогда не используется в производственной среде.
В таких случаях вам нужно что-то, что ждет готовности сервисов. Docker рекомендует использовать wait-for-it, Dockerize или wait-for. Однако обратите внимание, что готовность порта не всегда является признаком того, что служба готова к использованию. Например, в интеграционном тесте с использованием определенной базы данных SQL с определенной схемой порт становится доступным при инициализации базы данных, однако тест может работать только после применения определенной миграции схемы. Сверху могут потребоваться проверки для конкретного приложения.
#docker
Грех 4. Вы, например, запускаете БД в режиме docker-compose, а ее тест - на хосте.
Вот ситуация: вы хотите запустить несколько модульных тестов, но эти тесты зависят от некоторых внешних служб. Может быть база данных, может быть Redis, может быть другой API. Легко: давайте поместим эти зависимости в docker-compose и подключим к ним unit test.
Контейнерные тесты означают:
🔸Вы находитесь в той же сети Docker, поэтому настройка подключения такая же, как и для запуска службы в Compose. Конфигурация становится чище.
🔸Интеграционный тест не зависит от какой-либо другой конфигурации локальной системы или настройки среды, например… ваших учетных данных JFrog или каких-либо зависимостей сборки. Контейнер изолирован.
🔸Если другой группе необходимо запустить ваши тесты для обновленной версии службы, от которой зависят тесты, вы можете просто поделиться образом интеграционного тестирования - им не нужно компилировать или настраивать набор инструментов для сборки.
🔸Если в результате получается несколько отдельных контейнеров для интеграционных тестов, как правило, их можно запускать все одновременно и параллельно.
Совет по использованию контейнерных интеграционных тестов - использовать для них отдельное определение docker-compose. Например, если большинство ваших сервисов существует в docker-compose.yml, вы можете добавить docker-compose.test.yml с настройками интеграционных тестов. Это означает, что docker-compose up вызывает ваши обычные службы, а docker-compose -f docker-compose.yml -f docker-compose.test.yml up запускает ваши интеграционные тесты.
#docker
Вот ситуация: вы хотите запустить несколько модульных тестов, но эти тесты зависят от некоторых внешних служб. Может быть база данных, может быть Redis, может быть другой API. Легко: давайте поместим эти зависимости в docker-compose и подключим к ним unit test.
Контейнерные тесты означают:
🔸Вы находитесь в той же сети Docker, поэтому настройка подключения такая же, как и для запуска службы в Compose. Конфигурация становится чище.
🔸Интеграционный тест не зависит от какой-либо другой конфигурации локальной системы или настройки среды, например… ваших учетных данных JFrog или каких-либо зависимостей сборки. Контейнер изолирован.
🔸Если другой группе необходимо запустить ваши тесты для обновленной версии службы, от которой зависят тесты, вы можете просто поделиться образом интеграционного тестирования - им не нужно компилировать или настраивать набор инструментов для сборки.
🔸Если в результате получается несколько отдельных контейнеров для интеграционных тестов, как правило, их можно запускать все одновременно и параллельно.
Совет по использованию контейнерных интеграционных тестов - использовать для них отдельное определение docker-compose. Например, если большинство ваших сервисов существует в docker-compose.yml, вы можете добавить docker-compose.test.yml с настройками интеграционных тестов. Это означает, что docker-compose up вызывает ваши обычные службы, а docker-compose -f docker-compose.yml -f docker-compose.test.yml up запускает ваши интеграционные тесты.
#docker
Вы неправильно используете docker-compose
Полный собранный перевод :
https://habr.com/ru/post/550634/
#docker
Полный собранный перевод :
https://habr.com/ru/post/550634/
#docker
Интересное поведение #docker.
Есть контейнер с примонтированной через volume папкой допустим на хосте /opt/project1/, а внутри контейнера - /var/www
Кладем туда любой файл.
Контейнер и соответственно приложение не видит этого файла. Перезапускаем контейнер и тогда файл виден.
Делаем umount /opt/project1/folder1.
А контейнер продолжает видеть смонтированный диск и его содержимое до своего перезапуска.
Что почитать про это поведение - может кто сталкивался?
Есть контейнер с примонтированной через volume папкой допустим на хосте /opt/project1/, а внутри контейнера - /var/www
docker run -v /opt/project1:/var/www....На хосте делаем mount второго диска (sdb1) в папку /opt/project1/folder1.
Кладем туда любой файл.
Контейнер и соответственно приложение не видит этого файла. Перезапускаем контейнер и тогда файл виден.
Делаем umount /opt/project1/folder1.
А контейнер продолжает видеть смонтированный диск и его содержимое до своего перезапуска.
Что почитать про это поведение - может кто сталкивался?
В контейнере #docker есть пользователь, допустим:
не должен пустить. Значит
www-data:x:1000:1000:www-data:/var/www:/usr/sbin/nologinказалось бы теоретически docker exec —user=www-data ... /bin/bash
не должен пустить. Значит
/usr/sbin/nologin- это то, какая оболочка запускается автоматически при логине пользователя, а поскольку
docker exec - это запуск процесса без логина , то запускается все что мы ему скажем. Очевидно, но иногда думаешь "а вдруг сработает".В свежих версиях docker доступна команда docker scan Она позволяет сканировать образы на уязвимости (на движке Snyk). Надо предварительно залогиниться в Docker Hub: docker login
docker scan --file путь_к_Dockerfile локальный_образ
Получаем отчет об уязвимостях в виде списка, информацию об уровне серьезности, слоях образов, в которых проявляются уязвимости, степени зрелости эксплойтов и предложениях по исправлению.
#docker #devsecops
Подробности тут: https://docs.docker.com/engine/scan/
docker scan --file путь_к_Dockerfile локальный_образ
Получаем отчет об уязвимостях в виде списка, информацию об уровне серьезности, слоях образов, в которых проявляются уязвимости, степени зрелости эксплойтов и предложениях по исправлению.
#docker #devsecops
Подробности тут: https://docs.docker.com/engine/scan/
Docker Documentation
Docker Scout
Get an overview on Docker Scout to proactively enhance your software supply chain security
Статья про варианты угроз безопасности при использовании Docker контейнеров:
- Уязвимости хоста
- Ошибки настройки Docker Daemon
- Уязвимости уровня Docker images
- Проблемы runtime-конфигурации
- Проблемы при хранении и доставке образов
- Открытый доступ к Docker-сокету по сети или из других контейнеров
И парочка советов от автора как избежать этих проблем
#docker #иб
https://habr.com/ru/company/dataline/blog/567790/
- Уязвимости хоста
- Ошибки настройки Docker Daemon
- Уязвимости уровня Docker images
- Проблемы runtime-конфигурации
- Проблемы при хранении и доставке образов
- Открытый доступ к Docker-сокету по сети или из других контейнеров
И парочка советов от автора как избежать этих проблем
#docker #иб
https://habr.com/ru/company/dataline/blog/567790/
Довольно любопытная статья
https://blog.crunchydata.com/blog/deep-postgresql-thoughts-resistance-to-containers-is-futile
в которой пытаются оспорить довод о том что базы данных не желательно использовать в контейнерах.
В качестве аргумента приводится пример с PostgreSQL установленным локально и оказывается, что cgroup и namespace обеспечивают работу его процессов (тоже как при использовании докера).
По мне весьма сомнительная аргументация. Ведь насколько знаю cgroup и namespace обеспечивают работу всех процессов. В любой момент времени любой процесс принадлежит одному экземпляру namespace.
Может я не прав и действительно Postgres локально запущенный равен Postgres в контейнере?
#postgres #docker
https://blog.crunchydata.com/blog/deep-postgresql-thoughts-resistance-to-containers-is-futile
в которой пытаются оспорить довод о том что базы данных не желательно использовать в контейнерах.
В качестве аргумента приводится пример с PostgreSQL установленным локально и оказывается, что cgroup и namespace обеспечивают работу его процессов (тоже как при использовании докера).
По мне весьма сомнительная аргументация. Ведь насколько знаю cgroup и namespace обеспечивают работу всех процессов. В любой момент времени любой процесс принадлежит одному экземпляру namespace.
Может я не прав и действительно Postgres локально запущенный равен Postgres в контейнере?
#postgres #docker
Crunchy Data
Deep PostgreSQL Thoughts: Resistance to Containers is Futile
Recently I ran across grand sweeping statements that suggest containers are not ready for prime time as a vehicle for deploying your databases. The definition of "futile" is something like "serving no useful purpose; completely ineffective". See why I say…
Есть довольно старая статья в котором описан оверхед при работе базы Mysql в контейнерах при различных параметрах настройки сети контейнера.
#docker #базыданных
https://dzone.com/articles/testing-docker-multi-host-network-performance
#docker #базыданных
https://dzone.com/articles/testing-docker-multi-host-network-performance
DZone
Testing Docker Multi-Host Network Performance
In this post, I’ll review Docker multi-host network performance.
Кстати по namespace-ам есть неплохая статья для понимания что это и как они работают
#docker
https://habr.com/ru/post/458462/
#docker
https://habr.com/ru/post/458462/
Хабр
Глубокое погружение в Linux namespaces
Часть 1 Часть 2 Часть 3 Часть 4 В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run –...
На гитхабе собраны ссылки на книги, блоги, видео, кейсы и инструменты связанные с безопасностью docker контейнеров
#docker #devsecops
https://github.com/myugan/awesome-docker-security
#docker #devsecops
https://github.com/myugan/awesome-docker-security
GitHub
GitHub - myugan/awesome-docker-security: 📚 A curated list of awesome Docker security resources
📚 A curated list of awesome Docker security resources - GitHub - myugan/awesome-docker-security: 📚 A curated list of awesome Docker security resources
Сборник awesome на github полезных devops:
#linux: Awesome-Linux-Software
#devops: awesome-devops
#sysadmin: awesome-sysadmin
#nginx: awesome-nginx
#kubernetes: awesome-kubernetes
#docker: awesome-docker
#aws: awesome-aws
#googlecloud: awesome-google-cloud
#иб: awesome-security
#linux: Awesome-Linux-Software
#devops: awesome-devops
#sysadmin: awesome-sysadmin
#nginx: awesome-nginx
#kubernetes: awesome-kubernetes
#docker: awesome-docker
#aws: awesome-aws
#googlecloud: awesome-google-cloud
#иб: awesome-security
GitHub
GitHub - luong-komorebi/Awesome-Linux-Software: 🐧 A list of awesome Linux softwares
🐧 A list of awesome Linux softwares . Contribute to luong-komorebi/Awesome-Linux-Software development by creating an account on GitHub.
👍1
Инструмент о котором не слышал до этого, но очень полезный. В статье описывается автоматическая пересборка контейнеров docker или kubrrnetes при изменении определенных файлов или директорий.
Обычно с основным кодом сервисов если он написан на языке не требующем компиляции (php, python) просто монтирую volume.
Как мне кажется эта штука будет удобна при непосредственном изменении файлов самой сборки docker. Изменили, docker-compose.yml или Dockerfile например, и точно знаем что контейнер не забыли пересобрать.
https://habr.com/ru/articles/786282/
#docker
Обычно с основным кодом сервисов если он написан на языке не требующем компиляции (php, python) просто монтирую volume.
Как мне кажется эта штука будет удобна при непосредственном изменении файлов самой сборки docker. Изменили, docker-compose.yml или Dockerfile например, и точно знаем что контейнер не забыли пересобрать.
https://habr.com/ru/articles/786282/
#docker
Хабр
Синхронизация локальных изменений с docker/kubernetes контейнером
Думаю, это знакомая ситуация, когда вы решили создать какой-то сервис, написали первичный код, завернули это в контейнер, запустили в docker или в kubernetes, и все заработало...но вам понадобилось...
🔥2