Ребята из 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 в пару раз быстрее.
Как делать отладку приложений Node.js в Kubernetes?
Нам повезло ー у Node.js отличная поддержка в отношении удаленной отладки. Как с ней работать в Kubernetes отлично написано в этой статье.
Нам повезло ー у Node.js отличная поддержка в отношении удаленной отладки. Как с ней работать в Kubernetes отлично написано в этой статье.
#devopsспросил_devopsответил
Как лучше подключить статические данные к контейнеру ~10 GB по локальной сети и если S3 недоступен?
Во-первых, вопрос к ~10 GB – не очень хорошо, что контейнер слишком большой. Любой контейнер, который больше 300 MB, явление сомнительное. Но если говорить о S3, то его невозможно подключить к контейнеру, потому как к S3 мы всегда обращаемся через AWS CLI. Можем взять статистические данные у AWS, добавить в свой контейнер, что, в свою очередь, увеличит его, и после этого им пользоваться. Можно сделать cron, что будет обновлять данные каждые 5-10 секунд, но такое решение не совсем корректное.
Как лучше подключить статические данные к контейнеру ~10 GB по локальной сети и если S3 недоступен?
Во-первых, вопрос к ~10 GB – не очень хорошо, что контейнер слишком большой. Любой контейнер, который больше 300 MB, явление сомнительное. Но если говорить о S3, то его невозможно подключить к контейнеру, потому как к S3 мы всегда обращаемся через AWS CLI. Можем взять статистические данные у AWS, добавить в свой контейнер, что, в свою очередь, увеличит его, и после этого им пользоваться. Можно сделать cron, что будет обновлять данные каждые 5-10 секунд, но такое решение не совсем корректное.
Make JSON greppable!
Gron ー инструмент для преобразования файлов JSON в дискретные задания. Gron упрощает работу с API, которые возвращают большие двоичные файлы, но имеют никудышную документацию. Больше ー на странице проекта в Github.
Gron ー инструмент для преобразования файлов JSON в дискретные задания. Gron упрощает работу с API, которые возвращают большие двоичные файлы, но имеют никудышную документацию. Больше ー на странице проекта в Github.