
0sennijLis
Свободная и доступная память в Linux
Несмотря на достаточно спорный заголовок, рассуждения ниже будут отнюдь не о безнравственном поведении памяти в Linux.
Время от времени нам полезно знать как именно наша система использует память, так что в статье будет предпринята попытка объяснить разницу между свободной памятью, и доступной.
Свободная vs. Доступная память
Давайте сразу к делу. Итак, что такое свободная память, и чем она отличается от доступной.
Свободная память (free memory) - это объем памяти, который сейчас ни для чего не используется. По этой причине, особенно на серверах, удобно воспринимать свободную память, как тратящуюся впустую. После того, как ваши приложения/процессы были запущены и прошло значительное время безотказной работы, это число почти всегда должно быть небольшим.
Доступная память (available memory) - это объем памяти, который доступен для выделения новому или существующему процессу. Доступная память оценивается в количестве памяти которую можно выделить, без использования подкачки.
Ключевая разница между свободной и доступной памятью заключается в том, что свободная память не использована, и не занята ничем. Тогда как в противоположность ей, доступная память используется, и включает в себя, помимо прочего, кэши и буферы, которые можно освободить без снижения производительности за счёт использования свопа.
Сравнение свободной и доступной памяти на практике
Учитывая всё вышесказанное, давайте взглянем на пару серверов Linux с 60 гигами памяти на борту, 12 ядрами и swap разделом на Raid 10 собранном из NVMe накопителей. Условно обозначим их как "Server A" и "Server B". В первую очередь воспользуемся командой free.
free -h
Вывод будет примерно похож на демонстрируемый на скриншотах ниже (там так же выполнена команда uptime, чтобы показать, что сервера живут без ребута уже достаточно давно)
У этого сервера меньше 1% свободной памяти, и 13% доступной
А вот здесь, спустя 153 дня работы 30гигов памяти по прежнему тратятся впустую
На этих скриншотах хорошо видна разница между свободной и доступной памятью. При сравнении двух систем явно видно, что даже несмотря на то, что средняя загрузка у них очень похожая (обрабатываются одни и те же рабочие нагрузки), один сервер использует практически 100% памяти (Server A), а второй тратит больше 50% памяти впустую (Server B).
Обратите внимание, что ядро Linux переместит наименее часто используемые страницы памяти в пространство подкачки, даже если имеется доступная память.
При взгляде на эти системы любой админ задастся сразу несколькими справедливыми вопросами:
Замедляет ли свопинг производительность на сервере A
Следует ли вытащить пару плашек из сервера B, чтобы задействовать в другом месте?
Например может задействовать в сервере А, которому явно не хватает?
Ожидается ли в ближайшее время рост трафика/загрузки?
В часы пиковой нагрузки, когда задействован свпо, средняя загрузка остаётся ниже 12.00?
Можно ли настроить сервер B на использование большего количество буфферов и кэша?
Поскольку часть вопросов риторическая, то разумеется каждому администратору, при возникновении подобной ситуации придётся самому отвечать на них (или запрашивать помощь друга).
Заключение
Не позволяйте себе ловить себя на том, что вы смотрите на свободную память в вашей системе Linux и делаете поспешные выводы. Не забывайте, что вам также следует учитывать доступную память, буферы/кэши и другие факторы. Короче говоря каждый случай требует отдельного рассмотрения.
Для более детального изучения механизма управления памятью можно например почитать - https://docs.kernel.org/admin-guide/mm/index.html.
Разница между обратным прокси и ingress контроллером
Эта статья навеяна комментарием к предыдущей.
Обратный прокси
В предыдущей статье мы уже разбирали как работает обратный прокси, но повторение будет не лишним.
Обратный прокси можно в какой-то мере ассоциировать с старой телефонной станцией. Когда кто-то хочет воспользоваться телефоном, он сначала соединяется с коммутационным узлом, и общается с живым оператором, называя тому имя и адрес человека, которому нужно позвонить. После чего оператор соединяет звонящего с абонентом (при условии доступности второго).
Обратный прокси делает похожую работу, получая пользовательские запросы, и затем пересылая эти запросы на соответствующие сервера (как показано на картинке ниже).
У обратного прокси очень простая функция - он ставится перед приложением (или группой приложений), и служит посредником между пользователем и сервисом.
Как упомянуто выше, обратный прокси маршрутизирует пользовательские запросы на соответствующий сервер (при условии, конечно, что вы используете несколько серверов). На этом месте те, кто использует один сервер с одним экземпляром приложения, вполне справедливо зададутся вопросом, имеет ли вообще смысл внедрять обратный прокси-сервер. Ответ: да, смысл есть.
Обратный прокси будет полезен и в инсталляциях с одним сервером, за счёт предоставления таких своих преимуществ как: ограничение скорости, IP-фильтрация и контроль доступа, аутентификация, проверка запросов и кэширование.
Ingress контроллер
Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).
Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.
Чтобы лучше понять принцип работы, давайте сделаем шаг назад и попробуем разобраться, что такое Ingress.
Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.
Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.
Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).
В частности, входные контроллеры используются для:
предоставления нескольких служб под одним DNS-именем
реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами
реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами
реализации базовой аутентификации, или других методы контроля доступа для ваших приложений.
включения ограничения скорости для ваших приложения
Заключение
Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.
Понимание основных принципов работы прямых и обратных прокси-серверов
Это скорее статья-заметка. Без особого погружения в дебри технологий, и нюансы работы. Исключительно поверхностное рассмотрение основных различий.
Прежде чем начнём копаться в хитросплетениях прямых и обратных прокси-серверов, сначала стоит разобраться в общей концепции прокси-сервера как сущности, и понять его отличие от обычного сервера.
Представьте, что прокси-сервер - это официант в ресторане, который служит посредником между вами и поваром. Хоть он и не знает, как приготовить блюдо, но он знает что вы хотите заказать. В этой аналогии вы - клиент, повар - это обычный сервер, занимающийся приготовлением вашего блюда, а прокси-сервер - это официант.
Если говорить более формальными терминами, то:
Прокси-сервера - это посредники между клиентами, запрашивающими ресурсы, и серверами, предоставляющими ресурсы.
Различие между разными типами прокси-серверов (такими например как прямой и обратный) зависит от вашего сценария использования, и ваших специфичных требований. Давайте рассмотрим эти типы подробно.
Прямой прокси (Forward Proxy)
Этот тип серверов действует как посредник между клиентом и интернетом. Когда клиент запрашивает ресурс, прямой прокси-сервер получает доступ к ресурсу от имени клиента, и пересылает его обратно клиенту.
Вы можете задаться справедливым вопросом. Почему бы просто напрямую не отправлять запросы на сервер, не используя посредника? Есть несколько причин, по которым такой вариант не видится предпочтительным:
лучше контроль за интернет трафиком: Прямой прокси может разрешать или запрещать доступ к определённым ресурсам, контенту или сервисам, основываясь на описанных правилах. Это ценно для организаций, которые отслеживают и регулируют деятельность сотрудников или студентов в Интернете, а также для родителей, ограничивающих пребывание своих детей в Интернете.
экономия пропускной способности, и повышение скорости: с помощью кэширования часто посещаемых ресурсов прокси сервер ускоряет время загрузки страниц, и сокращает сетевой трафик.
улучшение приватности и безопасности: прокси-сервер может скрыть пользовательский IP адрес и другую идентификационную информацию от конечного сервера, что в свою очередь создаёт сложности для отслеживания пользователя. Он так же может шифровать пользовательские запросы и ответы, предотвращая перехват или взлом. Это большое преимущество для пользователей, которые хотят обезопасить свои персональные данные.
Обход цензуры: прокси помогает пользователям получать доступ к контенту и сервисам, которые заблокированы или запрещены в их сети (провайдером или правительством). Это достигается путем маршрутизации запросов через другое местоположение или IP-адрес, на которые не распространяются те же ограничения. Это выгодно для пользователей, которые ищут больше онлайн-свободы.
Обратный прокси (Reverse Proxy)
В противоположность прямому, обратный прокси-сервер позиционируется как посредник между интернетом и web-серверами. Он получает запросы от клиентов и направляет их на соответствующий сервер, в зависимости от различных факторов. Таких как алгоритмы балансировки нагрузки или доступности серверов. Такое равномерное распределение входящего трафика повышает масштабируемость и надежность веб-приложений.
Дополнительно обратный прокси может предоставлять возможности кэширования. Кэшируя статический контент, такой как изображения или файлы CSS, обратный прокси может предоставлять эти ресурсы напрямую клиентам, устраняя необходимость пересылать запросы на внутренние веб-серверы. Это существенно сокращает время отклика, и увеличивают общую производительность веб-приложения.
Другая важная фича обратного прокси - SSL Termination. Когда клиент запрашивает безопасное соединение (HTTPS), обратный прокси-сервер может обрабатывать процессы шифрования и дешифрования, освобождая серверные серверы от этой ресурсоёмкой задачи. Это не только улучшает производительность приложений, но еще и упрощает управление сертификатами SSL.
Некоторые примеры обратных прокси:
Nginx: в особом представлении не нуждается. Это высокопроизводительный open-source веб-сервер, который так же может работать в качестве обратного прокси. Он поддерживает различные протоколы, алгоритмы балансировки нагрузки, механизмы кэширования и настройки безопасности.
Varnish: Open-source обратный прокси-сервер HTTP с встроенным механизмом кэширования, предназначенный для ускорения веб-приложений.
Apache Traffic Server: Обратный и кэширующий сервер с открытым исходным кодом, способный обрабатывать миллионы одновременных подключений и различных протоколов.
Istio: Istio - это сервисная сетка с открытым исходным кодом, которая улучшает взаимодействие микросервисов с помощью таких функций, как обнаружение сервисов, балансировка нагрузки, маршрутизация трафика и многое другое.
Заключение
Таким образом, как прямые, так и обратные прокси-серверы играют ключевую роль в повышении безопасности, конфиденциальности и производительности интернет-коммуникаций. В то время как прямой прокси-сервер фокусируется на защите личности клиента и кэшировании ресурсов, обратный прокси-сервер превосходно распределяет трафик, кэширует контент и обрабатывает завершение SSL для веб-приложений.
Happy SysAdmin Day
Сегодня День Сисадмина!
День, чтобы сказать спасибо людям, стоящим за сложной технической инфраструктурой компании, которая просто работает для многих других людей. Потому что они делают чертовски хорошую работу и часто получают слишком мало похвалы! Потому что когда инфраструктурные службы работают в штатном режиме, мало кто задумывается - почему так.
По этой причине я желаю администраторам отличного дня и надеюсь, что вы сможете начать спокойные выходные!
Всем стабильного коннекта и благодарных пользователей!
Как DevOps'ам изучать Shell-скриптинг?
Действительно хорошие и целеустремлённые DevOps-инженеры обязаны уметь писать скрипты как минимум на sh/bash. По крайней мере стремиться освоить этот навык.
Эта статья представляет из себя краткое руководство (с рядом рекомендаций, и ссылок на полезные ресурсы), которое как поможет вам решать ежедневные задачи, так и поможет давать более корректные ответы на собеседовании.
Никогда не лишним будет заметить, что в любом обучающем процессе, особенно когда дело касается самообучения, очень важно иметь терпение и обладать должной самодисциплиной, чтобы не бросить на полпути.
Это руководство именно для тех, кто хотел бы разобраться в фундаментальных процессах. Для тех кому нужно решать задачи "по-быстрому" здесь и сейчас - есть stackoverflow и google.
1.Shell-скриптинг для DevOps
Первый вопрос, которым вы возможно задаётесь. А насколько действительно важен этот навык для DevOps-инженера? Этот вопрос абсолютно нормальный как в среде новичков, так и матёрых специалистов (да-да, такое тоже встречается).
Ответ прост: Да, это важно.
Картинка ниже хорошо иллюстрирует исследование stackoverflow, где 27% респондентов ответили, что пишут на shell.
Тут в догонку может прилететь второй вопрос.
Но у нас же полно различных средств автоматизации на любой вкус и под совершенно разные задачи? Может Shell всё таки того? Не нужен?
Ответ аналогичный первому: Shell всё еще жив, и всё еще очень нужен.
Да, может сейчас и не очень нужно создавать огромные портянки сценариев оболочки для автоматизации всего и вся, но для специальных задач для использования с инструментами автоматизации нам всё еще нужен Shell.
Например, если вы используете AWS user data, то весьма велика вероятность, что внутри него вы будете использовать скрипты на Shell. Другой пример, для создания образов AMI с помощью packer вы в конечном итоге будете применять Shell для конфигурации AMI. Также умение писать на баше может пригодится и при работе с системами управления конфигурацией, с контейнерами, и с многими другими системами.
Кроме того, сценарий оболочки пригодится для повторяющихся задач разработки. Например, это может быть развертывание Vagrant VM с необходимым программным обеспечением или настройка самой среды разработки.
Что наиболее важно, практическое написание сценариев и программирование становятся обязательными на предварительных собеседованиях в рамках собеседований DevOps. Так что это еще одна важная причина, по которой вам следует изучать сценарии оболочки.
2. Как начать писать на Shell?
Предварительное условия для начала - иметь опыт работы с Linux(или Unix). Следовательно прежде всего нужно убедиться, что вы комфортно себя чувствуете в командной строке Linux, и умеете работать с командами из пакета coreutils.
Если мир Linux для вас пока чужд, то стоит какое-то время потренироваться в виртуальной среде. Например развернув у себя локально абсолютно любой Linux в VirtualBox. Либо, воспользовавшись предложениями облачных провайдеров. Важно выбрать для начала широкоиспользуемый дистрибутив (ubuntu, fedora), так будет проще найти людей в сети, которым можно задать вопросы, и обсудить всплывающие проблемы. Если интересно копнуть глубже, и разобраться во внутренностях системы, то можно попробовать "продвинутые" дистрибутивы типа Arch или Gentoo (для особо упорных LFS). Но что совершенно точно не нужно, так это брать в руки всякую маргинальщину вроде KaliLinux или AstraLinux (во первых они основаны на более популярном и широко используемом дистрибутиве, а во вторых не во всяком линуксовом сообществе вас встретят с распростёртыми объятиями при упоминании таких поделок).
Если вы считаете, что достаточно хорошо умеете работать с Linux, то тогда сделайте следующее.
Создайте репозиторий на Github, создайте в нём каталог для каждого изучаемого вами аспекта, и коммитьте туда все ваши рабочие скрипты. Не имеет значения, будет репозиторий открытый или закрытый (хотя открытый обязывает более ответственно подходить к наполнению).
Заведите собственную документацию. Вы можете например оставлять в README ссылки на полезные источники. Поверьте - фиксирование информации в репозитории поможет вам сохранить знания, а также может помочь другим.
3. Какие есть бесплатные ресурсы для изучения программирования на Shell?
Вам совершенно точно не нужно платить за какие-либо расширенные курсы по изучению Shell-скриптинга, хотя на рынке есть достаточно предложений самых разных курсов для инженеров DevOps. Курсы (если они качественные) - это не плохо, и если вам комфортно обучаться в таком формате, то пожалуйста. Однако программирование на Shell - это тот навык, который вполне можно освоить самостоятельно.
Ниже представлен список бесплатных ресурсов для начала обучения. Некоторые ресурсы пересекаются по рассматриваемым темам. Поэтому выберете наиболее приемлемые по содержанию именно для вас, и начинайте работать с выбранным материалом от начала и до конца. Труд и самодисциплина, как уже упоминалось выше, здесь имеют самую важную роль.
Ссылки на сайты с интерактивными туториалами, бесплатными курсами, и pdf материалами (так как все ресурсы на английском, то тут у нас всплывает побочный квест - оттачивание навыка чтения технических текстов).
Shell Scripting tutorial [Web]
Bash Guide [web]
Shell Scripting Free Course [Udemy]
Bash Academy [Web]
Bash Reference manual [PDF]
The Linux command line [PDF]
4.Применение навыков Shell-скриптинга на практике.
Предположим вы уже изучили все основные концепции программирование на Shell, возможно написали несколько солидных скриптов в обучающих целях. Следующий справедливый вопрос у вас возможно будет "Ну и где мне теперь это всё применять?"
В первую очередь имеет смысл посмотреть существующие проекты автоматизации в своей компании. Особенно если компания не маленькая, и не решается одна точечная задача, то весьма вероятно, что в проектах найдётся не мало мест, где применяется Shell-скриптинг.
Если в вашей компании нет таких проектов, и вы как раз хотите заняться чем-то подобным, но не знаете с чего начать, то например можете посмотреть Git-репозитории с наиболее популярными образами контейнеров для Docker (например контейнер с Nginx).
Попытайтесь разобраться и понять как работают найденные Shell-скрипты. Попутно понимая работу базовых коцепций, и отмечая для себя нестандартные, но интересные пути решения, которые могут быть использованы в этих скриптах.
Не стоит конечно зацикливаться только на скриптах из контейнеров, вы можете найти скрипты во множестве других репозиториях open-source комьюнити.
5. Некоторые примеры для тренировки
Ниже приведены сценарии, которые вы можете реализовать с помощью Shell. Не каждый из них может пригодиться в реальной жизни, но вот на собеседовании они могут встречаться довольно часто. Так что будет полезно потренироваться над решением этих задач.
Найдите 10 самых больших файлов в системе, и перенаправьте вывод в файл.
Напишите скрипт для безопасного извлечения накопителей.
Напишите скрипт, отправляющий уведомление на почту.
Напишите скрипт для мониторинга загрузки CPU, памяти и дисков. Перенаправьте вывод с собранными данными в виде таблицы в файл, и уведомление в stdout если один их них превышает определённый порог.
Напишите сценарий для поиска созданных файлов и их размеров. Он должен принимать количество дней в качестве входных данных. Или формат от и до даты в качестве входных данных.
Напишите сценарий для автоматизации процесса создания новых учетных записей пользователей на сервере Linux и настройки их разрешений и доступа по SSH.
Напишите скрипт для создания списка пользователей, вошедших в систему по дате, и запишите его в выходной файл.
Напишите скрипт для рекурсивного копирования файлов на удалённую машину.
Напишите скрипт который отображает количество неудачных попыток входа в систему по IP-адресу
Создайте скрипт, который анализирует системный журнал, и пересылает в выходной файл выборку событий по конкретной службе, с отметками времени (в человекочитаемом формате).
Напишите скрипт, автоматизируйщий процесс архивирования системного журнала в каталог с резервными копиями, с последующей очисткой текущего журнала.
Напишите сценарий, проверяющий доступность списка URL, и отправляющий уведомление на почту, если какой-то из них не доступен.
Напишите скрипт для автоматизации процесса обновления нескольких серверов.
Напишите функцию, которая находит и убивает все зомби процессы в системе (задание со звёздочкой)
Не забывайте использовать в скриптах изученные понятия:
Переменные.
Подстановка команд, назначение результата переменным.
Использование cut, awk, и grep.
Перенаправление stdin/stdout/stderr.
Обработка условий с помощью if/elif/else.
Работу с оператором выбора (switch).
Циклы for/do-while)
Коды завершения (exit codes)
6.Вопросы по навыкам написания сценариев на собеседовании DevOps инженера.
Вопросы инженерам разнятся от компании к компании.
Например некоторые компании будут просто заинтересованы в ваших базовых знаниях Linux и сценариев оболочки. Другие компании будут рассчитывать на высокий уровень знаний командной строки Linux и сценариев оболочки.
Ниже приведены несколько примеров вопросов на собеседовании инженера DevOps.
Можете ли вы объяснить, как сценарии оболочки вписываются в более широкий рабочий процесс DevOps?
Зачем нужны сценарии оболочки, если есть другие инструменты автоматизации?
В решении каких задач вы предпочтете использовать Shell, а не Python/Golang?
Как провести статический анализ скрипта Shell?
Как вы можете гарантировать, что сценарий оболочки не содержит ошибок в CI/CD pipeline?
Как вы будете обрабатывать ошибки и исключения в своих сценариях?
Напишите простой скрипт, который принимает в качестве аргументов имена двух файлов, объединяет их и записывает вывод в третий.
Найдите дублирующиеся строки в файле, и замените их другой строкой.
Найдите все уникальные IP адреса в логе, и запишите их в отдельный файл
Как бы вы отлаживали сценарий оболочки, который работает неправильно?
Какая разница между циклами for и while?
7. Заключение
Разумеется этот пост не претендует на исчерпывающее рассмотрение темы (очень уж она большая, чтобы уместиться в один пост), но надеюсь, это краткое руководство по изучению сценариев Shell будет как минимум небесполезным для вас.
Неприятная ссылка на канал сообщества в телеграме
10 сравнительно новых DevOps инструментов, на которые стоит обратить внимание
В этой статье хотелось бы рассмотреть некоторые новые (относительно) инструменты DevOps, которые возможно кого-то заинтересуют, и при использовании помогут поднять производительность инженеров на новый уровень.
Pulumi
Давайте начнём с основы DevOps: инфраструктуры.
В первую очередь, Pulumi инструмент Infratructure as Code (IaC), в духе
Terraform, AWS CDK, CDK для Terraform итд.
Сегодня, хоть Terraform возможно и стал наиболее популярным выбором для IaC, у него есть ряд недостатков. Ну например:
Вы обязаны выучить новый "язык". В данном случае HCL.
HCL не достаточно функциональный (и я сейчас не про парадигму) язык, чтобы в нём было комфортно работать. Еще пару тройку лет назад в нём банально не было циклов for.
Но вернёмся к Pulumi.
Что он из себя представляет?
Если вы более-менее знакомы с AWS CDK, вам будет просто понять как он работает. Отличие может быть только в том, что он (Pulumi) пытается быть совместимым с каждым облаком.
Если вы еще не знакомы с AWS CDK, задумайтесь о знакомтсве: Pulumi позволяет вам управлять вашей инфраструктурой с любым (разумеется немаргинальным) языком программирования, который вы уже знаете. Это само собой исключает изучение еще одного ненужного в вашей жизни языка (если для вас конечно не ключевой задачей является строчка в резюме: HCL разработчик).
Короче говоря, если вы уже знакомы с какими-то языками программирования, например TypeScript, Python, Go, C#, Java, итд, и категорически не принимаете идею учить еще один новый язык - Pulumi для вас. Если вы используете AWS, технически вы можете использовать AWS CDK тоже, но если вы планируете заниматься оркестрацией гибридной облачной инфраструктуры, Pulumi сильно упростит вам жизнь.
Если вы уже используете Terraform в проде, но вас напрягают ограничения, накладываемые HCL, вы так же можете попытаться использовать Pulumi.
Этот инструмент давно не новый. Ему уже исполнилось почти 16к звездочек на github'e. Хотя по отношению к Terraform - он новый. Впрочем какая разница? Если он гипотетически может помочь решить ваши проблемы, то почему бы и не попробовать его?
SOPS
SOPS - сокращение от Secrets OPerationS. Это опенсорсный текстовый редактор файлов, который автоматически шифрует/дешифрует файлы.
Основные задачи на которых сосредоточено это приложение - редактирование, шифрование, и автоматизация.
Обычно, когда вы хотите зашифровать текстовый файл, вы делаете следущее:
Открываете любимый текстовый редактор, вносите правки в текст, и сохраняете файл.
Используете инструмент для шифрования/дешифрования для того, чтобы зашифровать весь файл.
Когда вам нужно прочитать зашифрованный файл:
Сначала берете специальный инструмент, и расшифровываете файл.
Открываете расшифрованный файл любимым текстовым редактором.
Недостаток этого процесса очевиден. Вам нужно два инструмента. С одной стороны текстовый редактор, с другой программа для шифрования информации. При этом задача остаётся на самом деле только одна.
И вот SOPS как раз и позволяет объединить два действия в одно.
Если очень кратко, он может быть интегрирован с такими сервисами как HashiCorp Vault, AWS KMS, etc) для расшифровки ваших зашифрованных файлов автоматически, а так же позволяет использовать git репозиторий для хранения ключей, что сильно упрощает рабочую коммуникацию.
Если вдруг заинтересовал инструмент, то в этой статье можно детально с ним ознакомиться.
Trivy
Контейнеризация и 12-факторные приложения (приложение как услуга) стали к настоящему времени настолько популярны, что когда у вас возникает задача что-то собирать и деплоить, вы не думаете ни о чём другом. С тех пор как мы стали зависимы от контейнеров в нашей инфраструктуре, стало важным поддерживать в актуальном состоянии безопасность хранимых образов, поскольку запускаемые из них контейнеры наследуют все характеристики родительских образов, в том числе уязвимости и неправильную конфигурацию.
Trivy - сканер безопасности. Он надёжен, быстро, и легок в использовании. У Trivy есть различные встроенные сканеры, которые призваны искать различные проблемы безопасности. Самый популярный вариант использования - поиск CVE. Второй по популярности - ошибки конфигурации.
Вы можете запускать Trivy как локально, с помощью CLI для сканирования локальных образов перед тем как отправлять их в реестр, или перед тем как деплоить ваше приложение.
Более того. Trivy разработан с возможностью без особого труда интегрироваться в CI пайплайны, что отлично согласуется с методологией DevOps.
Cluster API
Cluster API - это подпроект Kubernetes, ориентированный на предоставление декларативных API и оснастки упрощающей подготовку, обновление и эксплуатацию множества кластеров Kubernetes.
Запущенный Kubernetes Special Interest Group (SIG) Cluster Lifecycle, проект Cluster API использует API и шаблоны в стиле Kubernetes для автоматизации управления жизненным циклом кластера для операторов платформы. Вспомогательная инфраструктура, такая как виртуальные машины, сети, балансировщики нагрузки и VPC, а также конфигурация кластера Kubernetes определяются так же, как разработчики приложений развертывают свои рабочие нагрузки и управляют ими. Это обеспечивает согласованное и воспроизводимое развертывание кластера в самых разных инфраструктурных средах.
Если вас смущает официальное определение, подумайте так: вы можете запустить одну команду kubectl apply для создания кластера K8s, и она работает для AWS, Azure, DigitalOcean, Docker, GCP, OpenStack и других.
Не нужно создавать модули Terraform (или, что еще хуже, пытаться выяснить все параметры чужих модулей) для кластеров K8s, не нужно разбираться, как использовать eksctl для AWS и еще что-то для другого облака; просто применить kubectl для создания кластеров. Звучит впечатляюще, правда? Я знаю. Вот почему он и входит в этот список.
Linkerd
Linkerd - самая легкая и быстрая в мире service mash (по крайней мере, так говорят). Что такое service mash? Service mash — это выделенный уровень инфраструктуры для обеспечения безопасной, быстрой и надежной связи между сервисами.
Простота использования - вот ключевая фишка Linkerd. Вы можете установить его буквально одной командой.
Но давайте поговорим больше.
Настройка быстрая. Даже образы докеров маленькие, поэтому они загружаются быстрее.
Архитектура не сильно отличается. Существует плоскость управления и плоскость данных, где плоскость управления представляет собой набор служб, отвечающих за телеметрию, API, предоставление управляющих данных прокси плоскости данных и т. д., а плоскость данных имеет прокси, которые работают рядом с каждой службой. пример. Ознакомьтесь с официальным документом, если вы хотите узнать больше деталей.
Istio и AWS App Mesh используют прокси-сервер envoy с открытым исходным кодом — высокопроизводительный распределенный прокси-сервер C++, предназначенный для отдельных сервисов и приложений. Это сложный прокси общего назначения. Linkerd, с другой стороны, использует специально разработанный прокси-сервер, написанный на Rust, чтобы он был как можно меньше, легче и безопаснее. Я здесь не для того, чтобы судить, какой язык лучше и безопаснее, C++ или Rust, но как современный язык с особым способом управления памятью (собственность вместо сборки мусора) Rust определенно имеет преимущество.
Для управления несколькими кластерами, в отличие от Istio, Linkerd использует механизм зеркалирования сервисов. Настройка также относительно проста, почти как установка с одним кластером, за исключением того, что вам нужно сделать это дважды плюс плоскость управления с несколькими кластерами.
Подводя итог, Linkerd — это service mash другого типа: сверхлегкая, сверхпростая и сверхмощная. Linkerd добавляет безопасность, наблюдаемость и надежность в Kubernetes без каких-либо сложностей. Это не совсем новый инструмент, но если функции соответствуют вашим потребностям и вам нравится простота, попробуйте.
Github Actions
GitHub Actions — еще один CI.
Почему же тогда именно GitHub Actions?
Ну, во-первых, он находится в техническом радаре CNCF (и находится на стадии «оценки», превращая его в «новый» инструмент), поэтому нам как бы нужно хорошенько его рассмотреть.
Во-вторых, CI много взаимодействует с вашим кодом, и по своей природе GitHub Actions легко взаимодействует с вашими репозиториями GitHub. Больше никаких проблем с интеграцией CI с вашими репозиториями кода.
Еще одно преимущество для стартапов: у GitHub Actions есть некоторая бесплатная квота, поэтому, когда вы только что запустили новый продукт, бесплатной квоты может быть более чем достаточно, что делает его полностью бесплатным. Вам, вероятно, не нужно регистрировать несколько дополнительных самостоятельных исполнителей в течение довольно долгого времени, и вы экономите затраты на запуск некоторых виртуальных машин в каком-либо облаке для вашей собственной инфраструктуры только для части CI.
Tekton
Tekton... Ну... Это еще один CI)))
Ключевые особенности:
Можно запустить его в кластере K8s
Определить пайплайны как нативные ресурсы K8s, и просто применять применять их kubectl.
Теперь у него есть панель инструментов и интерфейс командной строки.
Кроме того, Tekton позволяет создавать, тестировать и развертывать в нескольких средах, таких как виртуальные машины или бессерверные решения. Вы также можете выполнять развертывание в различных облачных провайдерах или гибридных средах, используя конвейеры Tekton.
Стоит ли использовать его? Мое мнение, если:
Вы должны «владеть» своей системой CI (например, использование бесплатной квоты GitHub Actions по какой-то причине вам не подходит).
Вы уже используете K8s.
Вам нравится работать с K8s.
тогда определенно стоит попробовать Tekton.
HashiCorp Harness
Harness. О, это у нас еще один CI. НО на самом деле куда больше чем просто CI.
Оно объединяет несколько вещей в одно:
CI
CD/GitOps
feature flags
cloud costs
Harness предлагает размещенные виртуальные машины (ВМ) для запуска ваших сборок. С Harness Cloud вы можете без проблем создавать свой код на инфраструктуре, которую предоставляет Harness. Вы можете тратить меньше времени и усилий на обслуживание инфраструктуры и вместо этого сосредоточиться на разработке отличного программного обеспечения.
В Harness непрерывная доставка моделируется с использованием конвейеров и этапов. На каждом этапе вы определяете, что вы хотите развернуть с помощью служб, где вы хотите развернуть это с помощью сред и как вы хотите развернуть это с помощью шагов выполнения.
Harness GitOps позволяет выполнять развертывание GitOps в Harness. Вы определяете желаемое состояние службы, которую хотите развернуть, в своем манифесте Git, а затем используете Harness GitOps для синхронизации состояния с вашим работающим кластером Kubernetes.
Harness Feature Flags (FF) — это решение для управления функциями, которое позволяет вам изменять функциональность вашего программного обеспечения без развертывания нового кода. Это позволяет вам скрывать код или поведение без выпуска новых версий программного обеспечения. Флаг функции похож на мощный оператор if.
Короче говоря, если вы хотите, чтобы SaaS CI/CD/FeatureFlags были собраны в одном месте, это то, на что стоит обратить внимание.
Thanos
Здесь для начала следует немного вспомнить о локальном хранилище Prometheus.
Локальное хранилище Prometheus не предназначено для долговременного хранения; внешние решения обеспечивают длительное хранение и устойчивость данных.
Несмотря на то, что мы можем установить длительный период хранения данных, например годы, с помощью storage.tsdb.retention, вопрос остается в масштабе и планировании. С годами зондов с высоким разрешением обработка очень длинных запросов может занять много памяти. Это также зависит от масштаба: например, функция rate() в течение одного года с 15-секундным интервалом очистки требует 2,1 миллиона выборок или около 2,6 МБ данных. И это только по одному показателю.
Если у вас небольшая инфраструктура, нет ничего плохого в том, чтобы скорректировать время хранения до нескольких лет; текущая реализация TSDB отлично справляется с этим. Для более крупных приложений рассмотрите возможность использования более крупной распределенной базы данных TSDB.
И Thanos — это решение, которое решает эту проблему: это высокодоступная установка Prometheus с открытым исходным кодом и возможностями долгосрочного хранения, ориентированная на долгосрочное хранение. Если вы уже столкнулись с проблемами с хранилищем Prometheus, попробуйте Thanos.
HashiCorp Sentinel
Наконец поговорим про Sentinel.
Политика как код — это подход к управлению политиками, при котором политики определяются, обновляются, совместно используются и применяются с помощью кода, и Sentinel — это решение HashiCorp.
Поскольку Sentinel принадлежит HashiCorp, он хорошо интегрируется с другими продуктами HashiCorp. Так что, если вы активно пользуетесь Terraform, Vault, Consul или Nomad и хотите попробовать Policy-as-Code, Sentinel — именно то, что вам нужно.
Чтобы привести несколько конкретных примеров того, что могут сделать политики Sentinel:
Не позволяйте облачным ресурсам предоставляться без тегов с помощью Terraform.
Убедитесь, что изменение важных данных Vault может выполняться только авторизованными системными операторами с действительным MFA.
Разрешить рабочие нагрузки Docker только в Nomad.
Ключи Consul можно обновить только в рабочее время.
Пример короткого кода:
import “tfplan/v2” as tfplan
aws_instances = filter tfplan.resource_changes as _, rc {
rc.mode is “managed” and
rc.type is “aws_instance” and
rc.change.actions is not “delete”
}
main = rule {
all aws_instances as _, instance {
(instance.change.after.tags else {}) is not empty
}
}
Довольно очевидно, не так ли?