Новый проект для управления базами данных Oracle в Kubernetes. El Carro ーпортативный продукт, с открытым кодом, поддержкой комьюнити и без vendor lock-in оркестрацией контейнеров. Мощный декларативный API для конфигурации и деплоймента, а также для операций в режиме реального времени и мониторинга.
Новенькое чтиво подвезли: Terraform in Action, Scott Winkler
Книга рассказывает о модели Infrastructure-as-Code с использованием инструмента автоматизации Terraform. Вы научитесь проектировать и управлять серверами ー выделять, изменять, тестировать, развертывать. Книга учит читателей управлять инфраструктурой так же, как это можно делать с кодом.
Книга рассказывает о модели Infrastructure-as-Code с использованием инструмента автоматизации Terraform. Вы научитесь проектировать и управлять серверами ー выделять, изменять, тестировать, развертывать. Книга учит читателей управлять инфраструктурой так же, как это можно делать с кодом.
#devopsспросил_devopsответил
Можно останавливать контейнеры Docker командой SIGKILL?
Приложения, которые вы разворачиваете в контейнере, не всегда правильно работают с командой SIGKILL. Допустим, есть приложение, которое содержит привязку к базе данных. Если мы его «убьем» командой SIGKILL, connection pool не освободится, не закроется и будет висеть какое-то время, отбирая ресурсы машины. Особенно, в ситуациях, когда connection pool заполнен и есть всего одна база, на которую приходится основная нагрузка.
Важно правильно высвободить ресурс, чтобы на машинах, которые освобождаются, не оставалось memory links, т.е. «зомби-контейнеров», иначе ресурсы можно считать потерянными. Если у нас есть просто контейнер, не важно, как мы его «убьем». Если процесс становится «зомби-процессом», его останавливаем командой SIGKILL (в этом случае «stop» заберет время и ничем не поможет). А вот для оркестрации очень важно остановить контейнер правильно. Кстати, здесь пригодится делать и HEALTHCHECK контейнера.
Можно останавливать контейнеры Docker командой SIGKILL?
Приложения, которые вы разворачиваете в контейнере, не всегда правильно работают с командой SIGKILL. Допустим, есть приложение, которое содержит привязку к базе данных. Если мы его «убьем» командой SIGKILL, connection pool не освободится, не закроется и будет висеть какое-то время, отбирая ресурсы машины. Особенно, в ситуациях, когда connection pool заполнен и есть всего одна база, на которую приходится основная нагрузка.
Важно правильно высвободить ресурс, чтобы на машинах, которые освобождаются, не оставалось memory links, т.е. «зомби-контейнеров», иначе ресурсы можно считать потерянными. Если у нас есть просто контейнер, не важно, как мы его «убьем». Если процесс становится «зомби-процессом», его останавливаем командой SIGKILL (в этом случае «stop» заберет время и ничем не поможет). А вот для оркестрации очень важно остановить контейнер правильно. Кстати, здесь пригодится делать и HEALTHCHECK контейнера.
Ребята из rootly.io делятся списком нужных тулов для SRE-инженеров:
👉 Chaos engineering
👉 Monitoring and alerting
👉 Observability
👉 Paging tools
👉 SLO management
👉 Infrastructure-as-Code (and everything-as-code)
👉 Automated incident response
👉 Chaos engineering
👉 Monitoring and alerting
👉 Observability
👉 Paging tools
👉 SLO management
👉 Infrastructure-as-Code (and everything-as-code)
👉 Automated incident response
Краткий гайд по типичным ошибкам Distributed Computing
❗️ The network is reliable.
❗️ Latency is zero.
❗️ Bandwidth is infinite.
❗️ The network is secure.
❗️ Topology doesn't change.
❗️ There is one administrator.
❗️ Transport cost is zero.
❗️ The network is homogeneous.
❗️ The network is reliable.
❗️ Latency is zero.
❗️ Bandwidth is infinite.
❗️ The network is secure.
❗️ Topology doesn't change.
❗️ There is one administrator.
❗️ Transport cost is zero.
❗️ The network is homogeneous.
#devopsспросил_devopsответил
Что мы создаем в Docker – образ или контейнер?
Сразу хотим отметить, что из dockerfile мы создаем image (образ), а не контейнер. Кроме образа, которому мы присвоили тэг, создается еще два промежуточных образа, удалить которые нельзя.
Как работает билд на docker file: билд проходит по инструкциям, каждая инструкция делает «полезную работу», например, run или copy. Поднимается промежуточный контейнер, в нем выполняются эти команды. После этого промежуточные контейнеры останавливаются, делается commit, образуется слой и из слоев уже создается конечный образ. Если попытаться удалить один из этих промежуточных слоев, то мы не сможем собрать все вместе. При docker build имена stages можно давать произвольные, как alias в базах данных.
Рассмотрим такой пример: мы определились, что будет входить в состав приложения. У нас есть исходный образ и мы планируем добавлять в него файлы. Мы точно знаем, что туда будет входить, но, в то же время, не хотим, чтобы было много слоев. Какие наши действия? Рассматриваем все как одно целое. Или открываем контейнер, производим в нем манипуляции, делаем commit и получаем один образ. Похоже на ручную работу, но в данном случае так и есть. Чтобы автоматизировать такой процесс, нужно составить общую инструкцию.
Чтобы проверить, как создавали образ до вас (например, есть образ Alpine и мы не уверены, что его создали одной командой), можно проверить код в dockerfile на GitHub. Alpine Image – промежуточный, он не остается на машине, на которой собираем образ. Его можно удалить без последствий. Логическим пост-экшеном того, как мы собрали образ в multistage build, будет удаление промежуточных контейнеров.
Что мы создаем в Docker – образ или контейнер?
Сразу хотим отметить, что из dockerfile мы создаем image (образ), а не контейнер. Кроме образа, которому мы присвоили тэг, создается еще два промежуточных образа, удалить которые нельзя.
Как работает билд на docker file: билд проходит по инструкциям, каждая инструкция делает «полезную работу», например, run или copy. Поднимается промежуточный контейнер, в нем выполняются эти команды. После этого промежуточные контейнеры останавливаются, делается commit, образуется слой и из слоев уже создается конечный образ. Если попытаться удалить один из этих промежуточных слоев, то мы не сможем собрать все вместе. При docker build имена stages можно давать произвольные, как alias в базах данных.
Рассмотрим такой пример: мы определились, что будет входить в состав приложения. У нас есть исходный образ и мы планируем добавлять в него файлы. Мы точно знаем, что туда будет входить, но, в то же время, не хотим, чтобы было много слоев. Какие наши действия? Рассматриваем все как одно целое. Или открываем контейнер, производим в нем манипуляции, делаем commit и получаем один образ. Похоже на ручную работу, но в данном случае так и есть. Чтобы автоматизировать такой процесс, нужно составить общую инструкцию.
Чтобы проверить, как создавали образ до вас (например, есть образ Alpine и мы не уверены, что его создали одной командой), можно проверить код в dockerfile на GitHub. Alpine Image – промежуточный, он не остается на машине, на которой собираем образ. Его можно удалить без последствий. Логическим пост-экшеном того, как мы собрали образ в multistage build, будет удаление промежуточных контейнеров.
Моніторинг ー це не просто черговий етап розробки програмного забезпечення і не просто система, що поставляється з готовими серверними рішеннями. Вчасне виявлення недоліків та попередження аварійних ситуацій може врятувати як один сервер, так і комплексну інфраструктуру великої компанії. Підготували для вас підбірку кращих інструментів моніторингу з відкритим вихідним кодом.
Если вам нравится интерфейс HTTPie, но жутко не хватает функций curl, curlie ー то, что вам нужно. Curlie ー это фронтенд курла, который облегчает работу с HTTP.
Кейс использования Grafana dashboard: Визуализация Prometheus, использование местных ресурсов, GitHub и кое-что еще.
Нашли для вас неплохой онлайн-редактор для создания network policies в Kubernetes.
Мы уже рассказывали о Twelve-Factor App Methodology, но новый взгляд на методологию лишним не будет. Насколько релевантны эти правила сегодня?
#devopsспросил_devopsответил
Что будет, если убрать команду Docker entry point и оставить только CMD?
С командой CMD работать такой кейс будет, но без какой-либо гарантии. Например, пользователь поработал с кодом и случайно указал какой-то параметр в конце – в итоге все «сломается». В случае с entry point процесс запускается надежно – «перебить» entry point сложнее, чем CMD. В случае с CMD данные могут быть изменены неосознанно, случайно либо по какой-то другой причине. С entrypoint больше сложностей и, соответственно, больше гарантий работоспособности контейнера.
Может возникнуть вопрос: а если не указывать ни entry point, ни CMD, есть ли смысл задавать entry point при запуске контейнера? В таком варианте entry point наследуется из того, что было from, а там могут быть любые данные. Можно поменять пользователя, например, если кто-то работал под alpine user, можно указать «user root», и все запуститься под root.
Что будет, если убрать команду Docker entry point и оставить только CMD?
С командой CMD работать такой кейс будет, но без какой-либо гарантии. Например, пользователь поработал с кодом и случайно указал какой-то параметр в конце – в итоге все «сломается». В случае с entry point процесс запускается надежно – «перебить» entry point сложнее, чем CMD. В случае с CMD данные могут быть изменены неосознанно, случайно либо по какой-то другой причине. С entrypoint больше сложностей и, соответственно, больше гарантий работоспособности контейнера.
Может возникнуть вопрос: а если не указывать ни entry point, ни CMD, есть ли смысл задавать entry point при запуске контейнера? В таком варианте entry point наследуется из того, что было from, а там могут быть любые данные. Можно поменять пользователя, например, если кто-то работал под alpine user, можно указать «user root», и все запуститься под root.
Ошибки допускают все, ошибаться ー нормально. Но лучше учиться на ошибках других и не допускать их у себя в проекте. Читаем про то, как удалить базу данных прода и выжить.
В копилку полезных тулов: litestream
Инструмент репликации стриминга для SQLite. Запускается как фоновый процесс и безопасно реплицирует изменения в другой файл или S3. Коммуницирует только с SQLite через SQLite API, поэтому о безопасности базы можно не беспокоится.
Инструмент репликации стриминга для SQLite. Запускается как фоновый процесс и безопасно реплицирует изменения в другой файл или S3. Коммуницирует только с SQLite через SQLite API, поэтому о безопасности базы можно не беспокоится.
#devopsспросил_devopsответил
Как в Docker работать с удаленным URL-адресом: ADD, curl, wget?
ADD – отдельный слой, с помощью которого можно добавить все необходимое. Но в таком случае нет экономии слоев. С целью сэкономить на слоях в Images часто используются команды curl и wget, но это не совсем корректно. Есть специально предназначенная для этого команда ADD, ее и стоит использовать. Но если, к примеру, возникла необходимость что-то добавить в пакетный менеджер, в таком случае лучше применить curl и wget. Для всего остального есть ADD.
Как в Docker работать с удаленным URL-адресом: ADD, curl, wget?
ADD – отдельный слой, с помощью которого можно добавить все необходимое. Но в таком случае нет экономии слоев. С целью сэкономить на слоях в Images часто используются команды curl и wget, но это не совсем корректно. Есть специально предназначенная для этого команда ADD, ее и стоит использовать. Но если, к примеру, возникла необходимость что-то добавить в пакетный менеджер, в таком случае лучше применить curl и wget. Для всего остального есть ADD.
Полезные плагины: lift
Lift ー это плагин, усиливающий AWS CDK для расширения функций Serverless Framework.
Lift ー это плагин, усиливающий AWS CDK для расширения функций Serverless Framework.
Те, що CI/CD є однією з найважливіших практик DevOps ー відомий факт. Але як буде розвиватися цей потужний напрямок далі? Підхід DevOps тісно пов'язаний із штучним інтелектом, безсерверними архітектурами, мережевою безпекою та іншими сучасними технологіями. У нашій статті розповіли про цей зв'язок та поділилися підбіркою популярних інструментів CI/CD з відкритим кодом.
#devopsспросил_devopsответил
Параллельные процессы в Docker – возможно?
Команда Docker entry point позволяет запускать только один процесс, и именно он обеспечивает работоспособность контейнера. Теоретически, можно запустить еще один процесс, но с него не останется никаких логов, и сам процесс будет «подвисшим». Если вдруг «упадет» главный процесс, то второй процесс станет неуловимым – не ясно, что с ним происходит и что с ним делать.
Параллельные процессы в Docker – возможно?
Команда Docker entry point позволяет запускать только один процесс, и именно он обеспечивает работоспособность контейнера. Теоретически, можно запустить еще один процесс, но с него не останется никаких логов, и сам процесс будет «подвисшим». Если вдруг «упадет» главный процесс, то второй процесс станет неуловимым – не ясно, что с ним происходит и что с ним делать.
#DevOps_tools
Kui ー фреймворк для гибкой работы в cloud-native разработке. Командная строка, которая облегчает процесс работы с командами. Визуально приятная графика вместо скучных таблиц, моментальное копирование и вставка с помощью одного клика, а еще обработка команд kubectl в пару раз быстрее.
Kui ー фреймворк для гибкой работы в cloud-native разработке. Командная строка, которая облегчает процесс работы с командами. Визуально приятная графика вместо скучных таблиц, моментальное копирование и вставка с помощью одного клика, а еще обработка команд kubectl в пару раз быстрее.