Перестал запускаться minikube
Доброго дня! Может кто уже сталкивался и как то решил. Зависает запуск minikube
Docker на практике
Книга "Docker на практике" Иана Милла, Эйдана Хобсона и Сейерса - это практическое руководство, которое позволяет читателям изучить и использовать технологию контейнеризации Docker. Благодаря подробным объяснениям, примерам кода и наглядным иллюстрациям, авторы позволяют читателям получить полное представление о том, как использовать Docker для разработки, тестирования и развертывания приложений.
Аннотация представляет собой полезное описание содержания книги, в котором указываются основные темы, концепции и примеры, рассмотренные в книге.
Книга начинается с введения в Docker, где объясняются основные понятия и преимущества контейнеризации. Затем авторы рассматривают основные этапы работы с Docker, включая установку и конфигурацию, создание Docker-образов и контейнеров, а также управление развертыванием и масштабированием приложений.
В следующих главах книги подробно описываются различные аспекты использования Docker в разработке и тестировании приложений. Для этого рассматриваются такие темы, как создание и использование сред для разработки, использование инструментов для автоматизации тестирования и развертывания, а также интеграция Docker с другими технологиями разработки.
Особое внимание уделено безопасности и мониторингу в контексте Docker. Авторы рассматривают различные сценарии защиты Docker-контейнеров и предлагают рекомендации по работе с проблемами безопасности. Они также представляют инструменты и методы для мониторинга и отладки приложений на Docker.
Книга "Docker на практике" также включает в себя примеры реальных проектов, где авторы демонстрируют, как применять Docker в различных сценариях. Эти примеры помогают читателям лучше понять, как использовать Docker в реальной жизни.
В целом, "Docker на практике" является полезным руководством для разработчиков и системных администраторов, которые хотят освоить Docker и использовать его для разработки и развертывания приложений. Авторы предоставляют читателям практические инструменты и советы, которые позволяют быстро и эффективно начать работу с Docker.
Книгу можно скачать в ТГ канале https://t.me/bitebusters/39
ГОТОВИМ DOCKERFILE ДОМА
Привет! Прошлый ролик по докеру не зашёл, а залетел просто! Комментарии просто взорвались, как и моя пятая точка от некоторых из них)))
И я решил снять продолжение! Надеюсь вам понравится!
DOCKER БЫТОВОЙ УРОВЕНЬ
Привет! Это небольшой гайд для новичков в Docker, который должен помочь тебе начать пользоваться докером!
Как создавать софт, как SRE
Перевод очень интересной статьи "How to Build Software like an SRE", в которой разбираются подходы к созданию приложений с точки зрения SRE.
Принципы надежности и компромиссы, усвоенные на собственном горьком опыте
Я занимаюсь этой “надежностью” уже некоторое время (около 5 лет), в компаниях, насчитывающих от 20 до более чем 2000 человек. Меня всегда в первую очередь всегда интересовали те элементы ПО, которые я описываю как живущие “вне” приложения — например, как приложение получает свою конфигурацию? На каких типах серверов оно запускается и являются ли эти типы наиболее подходящими? Что с ним происходит на пути от “кода в репозитории” до “запуска на проде”? И я всегда следил за тем, что мне нравится — какие механизмы позволяют быструю итерацию, а какие вызывают разочарование, какие приводят к сбоям, а какие предотвращают их.
Я думаю, что будет полезно, если я все это запишу, даже если это будет просто для меня в качестве справочника.
Обратите внимание, что этот список немного странный с точки зрения SRE. Моя цель не заключается в том, чтобы “построить все так, чтобы надежность была 100%”; это больше похоже на “как достичь 80% надежности, затратив 20% усилий, при этом позволяя разработчикам работать быстро”, что в конечном итоге дает нам систему, которая выглядит совсем по-другому. Но это стоит попробовать — если делать это хорошо, работа с продом становится интересной, а не уныло безопасной или ужасающе опасной.
Также, пожалуйста, сделайте мне одолжение и мысленно дополните каждый из следующих пунктов словом “обычно”. Каждая ситуация уникальна, и то, что я не сталкивался с тем, что (например) использование Git является плохой идеей, не означает, что такого случая не существует. “Только Ситхи всё возводят в абсолют”, и т.д.
Итак! Пройдя через всё это — вот как я бы начал все сначала, если бы мог.
Coding (параметры? да я их еле знаю!)
Никаких конфигов, зашитых в код. Если ваш сервис по какой-либо причине не может загрузить конфигурацию при запуске, он должен просто аварийно завершиться — этот случай гораздо проще диагностировать, чем результат того, что инстанс выполнил старый код, потому что никто не вспомнил о том, что нужно удалить строку config.get(enable_cool_new_thing, false).
Чрезвычайно строгие настройки RPC. Я говорю о нуле (или МОЖЕТ БЫТЬ одной) повторных попыток и таймауте, в 3 раза превышающем p⁹⁹. Здесь мы стремимся к предсказуемости, и многократные повторные попытки или длительные таймауты в качестве быстрого решения проблемы в работе сервиса превратятся в недельное расследование и головную боль через год. Исправьте неисправный сервис!
Никогда не отказывайтесь от локального тестирования. Это значительно сокращает время цикла разработки, чем необходимость полагаться (и возиться с этим) на CI или удаленные рабочие среды. Контейнеризация локальной тестовой среды может упростить управление зависимостями и обеспечить их переносимость между машинами.
Избегайте использования состояния как чумы. Управление сервисом с сохранением состояния (stateful) значительно сложнее, чем без сохранения состояния. Существует много хороших управляемых баз данных и кэшей, просто используйте один из них!
Merging (там, куда мы идем — тесты не нужны)
Используйте Git. Используйте его для всего — инфраструктуры, конфигов, кода, дашбордов, графиков дежурств. Ваш репозиторий Git — это источник истины, который можно восстановить на определенный момент времени.
Не тратьте время на полное покрытие кода тестами. И вообще, не занимайтесь “расстановкой галочек” — это только для красивых графиков и диаграмм, которые имеют очень мало общего с тем, какую фактическую ценность дает ваше изменение (см. ниже).
Уделяйте приоритетное внимание тестам в реальных условиях. Самый ценный тест, который занимает меньше всего времени, — это просто применение вашего изменения на стейджинге (или, еще лучше, на проде!) и демонстрация того, что оно делает то, что вы хотели, и не ломает всё. На втором месте по эффективности находятся интеграционные тесты, а юнит-тесты идут последними — то есть, “только если у вас есть на них время”.
При изменениях в инфраструктуре делайте планы максимально ясными и очевидными. Это может означать “положить Terraform Plan как коммент к пуллреквесту”, так же сделайте с diff helm. Существуют отличные инструменты, позволяющие убедиться, что изменения, которые, по вашему мнению, вы вносите, являются теми изменениями, которые вы вносите на самом деле, поэтому убедитесь, что они находятся в центре внимания.
При внесении изменений в код делайте регрессии максимально очевидными. Журналы ошибок, использование ЦП и частота ошибочных запросов являются отличными сигналами, позволяющими выявить около 90% плохих версий и работают для практически любого сервиса (полностью универсальны). Так что не отбрасывайте их!
Deploying (no sleep til prod)
Используйте Docker. Это отраслевой стандарт не просто так — разбор зависимостей в средах с такими инструментами, как Chef или Ansible, всегда проигрывает этой приятной автономности.
Развертывайте всё и всегда. Каждый день, который проходит без вашего деплоя, увеличивает вероятность того, что он на самом деле был незаметно сломан (в результате чьего-то изменения, обновления зависимостей, удаления стороннего API), и через две недели будет очень трудно выяснить, что и где пошло не так.
Проверяйте развертывания по мере их выполнения. Можете ли вы создать полностью поврежденный образ и успешно разлить его на все машины? Почему? Это можно исправить несколькими способами, включая canary/shadow развертывания или даже просто хорошими readiness проверками.
Включите ограничение на “мгновенное” развертывание конфигов. Это может показаться нелогичным (“мгновенное” часто означает “сломать все сразу и быстро”), но возможность отключить проблемную функцию или заблокировать IP менее чем за 5 минут с лихвой компенсирует повышенный риск. Это позволяет всё делать быстро, но управлять этим нужно осторожно!
Operating (my god, it’s full of pods)
Используйте Kubernetes. Предполагая, что у вас есть более одного сервиса и более одного инстанса, вам либо нужны, либо будут нужны такие вещи, как обнаружение сервисов, автоматическое масштабирование и управление версиями развертывания, и вы не хотите управлять всем этим самостоятельно. Kubernetes дает командам инфраструктуры сверхспособности масштабирования.
Используйте Helm. Или какой-то другой инструмент для управления манифестами Kubernetes, я не привередлив — главное, чтобы вы никогда не использовали прямые команды kubectl apply, edit или delete. Жизненный цикл ресурсов должен быть доступен в системе контроля версий.
Избегайте операторов и CRD (Custom Resource Definition). Как уже упоминалось выше, я люблю Kubernetes, но для очень многих разработчиков он очень сложен, и пользовательские операторы резко уходят в область “Что это за херня?”, что создает ему сложную репутацию. Пусть все будет просто.
Запускайте по 3 экземпляра всего. Как и с резервными копиями, два экземпляра — это один, а один — не существует :) Кроме того, убедитесь (действительно проверьте на проде), что 2 из 3 “штук” могут справиться с полной нагрузкой самостоятельно — в противном случае у вас на самом деле нет такой устойчивости к сбоям, как вы думаете.
Структурированные логи — это неотъемлемая часть. Вместе с идентификаторами трассировки они позволяют вам пройти 90% пути к APM (application performance monitoring), но при гораздо меньших затратах и усилиях со стороны разработчиков.
Итак, это текущий список! Думаю, что буду периодически возвращаться сюда и добавлять что-то еще. Пожалуйста, не стесняйтесь обращаться ко мне, если что-то из этого особенно вас раздражает или если у вас есть ещё что-то, о чем бы вы хотели бы поговорить 😜
Ответ на пост «А внутри винда с 1С»
А внутри винда с 1С
В Питере шаверма и мосты, в Казани эчпочмаки и казан. А что в других городах?
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Реклама АО «Кордиант», ИНН 7601001509