Делимся простой, но эффективной утилитой для создания и управления VPN ー WireGuard-Manager.
#devopsспросил_devopsответил
Разница между путем к dockerfile и docker context
Если при сборке указываем -f, мы показываем путь к докер-файлу. Dockerfile может лежать в одном месте, а контекст – в другом, и, по сути, между собой они не связаны. Dockerfile можно переместить, но он будет привязан к контексту папки, в которой лежат нужные файлы, и которые он будет себе копировать.
Контекст, по сути, это файловое окружение, которое мы используем в нашем докер-файле, а докер-файл – набор инструкций, и эти понятия не стоит путать. Dockerfile – файл с инструкциями для сборки, а контекст – файлы, которые мы будем использовать.
Если нет необходимости передавать файлы в контейнер, это не значит, что можно опустить контекст и совсем не указывать его. Чтобы с контекстом ничего не случилось, можно указать пустую папку, чтобы не копировать и не перемещать файлы по сети. Контекст должен указываться обязательно – это необходимый параметр по умолчанию для докер-файла.
Разница между путем к dockerfile и docker context
Если при сборке указываем -f, мы показываем путь к докер-файлу. Dockerfile может лежать в одном месте, а контекст – в другом, и, по сути, между собой они не связаны. Dockerfile можно переместить, но он будет привязан к контексту папки, в которой лежат нужные файлы, и которые он будет себе копировать.
Контекст, по сути, это файловое окружение, которое мы используем в нашем докер-файле, а докер-файл – набор инструкций, и эти понятия не стоит путать. Dockerfile – файл с инструкциями для сборки, а контекст – файлы, которые мы будем использовать.
Если нет необходимости передавать файлы в контейнер, это не значит, что можно опустить контекст и совсем не указывать его. Чтобы с контекстом ничего не случилось, можно указать пустую папку, чтобы не копировать и не перемещать файлы по сети. Контекст должен указываться обязательно – это необходимый параметр по умолчанию для докер-файла.
В помощь девопсам и адептам Microsoft Azure: о новых возможностях платформы для упрощения деплоймента, масштабирования и управления приложениями.
Аккаунты AWS сами по себе могут выступать в роли границы безопасности. В некоторых организациях их используют для отдельных окружений: например, один для среды разработки, второй – для тестирования, третий – для продакшена. Есть вариант выделения отдельного аккаунта для конкретной команды или проекта. Многочисленные примеры подтверждают, что работа с отдельными аккаунтами AWS – надежное решение.
А вы используете AWS-аккаунты в своей организации?
А вы используете AWS-аккаунты в своей организации?
Независимо от того, какое именно решение вы используете, вам точно пригодится список, как и для чего могут пригодится AWS accounts.
Сентябрь горит, ну а мы врываемся за новыми профессиональными знаниями. 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.