Сентябрь горит, ну а мы врываемся за новыми профессиональными знаниями. 9 сентября пройдёт бесплатный митап от Cloud Builders Community. На нём соберутся эксперты из Microsoft, Uber, GitLab, Intellias, чтобы поделиться своими лучшими практиками и опытом.
Программа ивента будет насыщенная. Нас ждут:
💥 Доклад о DevOps на платформе Oracle.
💥 Lightning talk с Владимиром Шинкарем (Senior Lead DevOps Engineer в Intellias).
💥 Два fireside chats в разных форматах. Johan Abildskov (Software Engineer из Uber) поделится своими кейсами DevOps автоматизации, а Владимир Клевко (Solution Architect в GitLab) расскажет, как в GitLab с ремоут-культурой поддерживают ментальное здоровье.
Все доклады будут на английском языке. Присоединиться к митапу можно прямо из дома, ведь мероприятие пройдёт в удобном онлайн-формате. Встретимся совсем скоро – 9 сентября в 19:00 ;)
Программа ивента будет насыщенная. Нас ждут:
💥 Доклад о DevOps на платформе Oracle.
💥 Lightning talk с Владимиром Шинкарем (Senior Lead DevOps Engineer в Intellias).
💥 Два fireside chats в разных форматах. Johan Abildskov (Software Engineer из Uber) поделится своими кейсами DevOps автоматизации, а Владимир Клевко (Solution Architect в GitLab) расскажет, как в GitLab с ремоут-культурой поддерживают ментальное здоровье.
Все доклады будут на английском языке. Присоединиться к митапу можно прямо из дома, ведь мероприятие пройдёт в удобном онлайн-формате. Встретимся совсем скоро – 9 сентября в 19:00 ;)
Керувати віртуальними машинами ― це як керувати світом...Ну це ми, можливо, трохи перебільшили, але насправді ефективна робота з віртуальним залізом вкрай важлива для будь-кого, хто пов'язаний з розробкою чи мережевою інфраструктурою. Розкриваємо карти: гіпервізор Hyper-V стане у нагоді справжнім володарям віртуалок. Почитати про нього можна у нашій статті.
#devopsспросил_devopsответил
Какие бывают ошибки docker login?
Разберем ошибку “Error saving credentials: error storing credentials – err: exec: ""docker-credential-secretservice"": executable file not found in $PATH, out: ``”. Можно использовать рекомендации по установке GPG. Но, допустим, в данном примере есть вторая машина, на которой все инсталлировано аналогично, GPG не настроен, а docker login проходит без ошибок. Какие еще могут быть причины?
Первый вариант – на машине не создана папка docker credentials, нет файла с кредами и Docker не может их получить. Второй вариант – нужно попробовать установить docker-credential-secretservices и проверить, как работают обе машины с этим компонентом и без него.
Второй пример: “Error saving credentials: error storing credentials – err: exit status 1, out: `Failed to execute child process “dbus-launch” (No such file or directory)”. Здесь, вероятнее всего, у вас недостаточно прав на папку – возможно, работаете под пользователем, у которого нет определенных доступов к папке Docker credentials – вся архитектура могла создаваться другим пользователем.
Какие бывают ошибки docker login?
Разберем ошибку “Error saving credentials: error storing credentials – err: exec: ""docker-credential-secretservice"": executable file not found in $PATH, out: ``”. Можно использовать рекомендации по установке GPG. Но, допустим, в данном примере есть вторая машина, на которой все инсталлировано аналогично, GPG не настроен, а docker login проходит без ошибок. Какие еще могут быть причины?
Первый вариант – на машине не создана папка docker credentials, нет файла с кредами и Docker не может их получить. Второй вариант – нужно попробовать установить docker-credential-secretservices и проверить, как работают обе машины с этим компонентом и без него.
Второй пример: “Error saving credentials: error storing credentials – err: exit status 1, out: `Failed to execute child process “dbus-launch” (No such file or directory)”. Здесь, вероятнее всего, у вас недостаточно прав на папку – возможно, работаете под пользователем, у которого нет определенных доступов к папке Docker credentials – вся архитектура могла создаваться другим пользователем.
Для новичков в программировании: метод trim () в JavaScript. Полезные основы веб-программирования от автора YouTube-канала Dev Newbs.
Новый проект для управления базами данных 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, поэтому о безопасности базы можно не беспокоится.