Sr. DevOps Engineer
Данная статья представляет собой решение проблемы с network latency между прикладом и бд. Поэтому скорее всего она будет интересна людям имеющие схожие симптомы. В материале описаны основные моменты kubernetes и пляски с бубном на python. Примеры кода приведены из реального приложения.
Рассказываем, как начинающему разработчику установить и управлять различными версиями Python с помощью Pyenv, подготовить свой проект и создать виртуальное окружение через Poetry.
В первой части мы спроектировали микросервисную архитектуру.
Во второй части разработали RESTful API Service на Golang cо Swagger и авторизацией.
Третья часть была посвящена знакомству с графовой БД Neo4j и работе над микросервисами CategoryService и APIService.
Четвертая часть была посвящена разработке микросервисов.
Мы продолжаем создание системы заметок. На этот раз посмотрим на разработанный File Service, который работает с хранилищем MinIO. Но сначала разберёмся с самим хранилищем и его настройкой.
Удивительно, что в 2021-м все еще можно обсуждать такую избитую тему. Однако, мне пришлось пройти довольно длинный путь от покупки охранных камер до готового решения, покрывающего мои, довольно нехитрые, задачи. Под катом вы найдете скрипт, который показался мне достаточно удачным, чтобы опубликовать его на Хабре, и некоторые пояснения к нему. Надеюсь, кому-то поможет.
Привет! Подошел к концу двенадцатый набор в Школу Программистов hh.ru. Самое время рассказать, как Петр Васильевич раздавал премии менеджерам, кто вышел победителем из "Релиза до выходных" благодаря ролевому помощнику, и как впервые в истории Школы нам пришлось облегчить условия вступительного задания прямо во время набора.
В этой статье будет подробный разбор заданий свежего набора в Школу Программистов hh.ru.
Привет! Меня зовут Игорь, я управляющий партнер в KTS.
Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах.
Сегодня мы на практике разберем, что нужно делать, чтобы ваше приложение оказалось в Интернете. Какие-то моменты я опущу, чтобы на забираться слишком глубоко.
В статье мы пройдем путь от написания кода до запуска в Интернете, рассмотрим необходимые для этого абстракции в Kubernetes, задеплоим приложение в облаке и разберем, что для этого необходимо.
Привет! Меня зовут Мария, я DevOps-инженер в компании Wrike. В этой статье расскажу о работе DevOps-инженеров с командами разработчиков: как выглядит процесс взаимодействия, из каких этапов состоит и как построить его с нуля. Статья будет полезна, если вы часто меняете проекты и каждый раз вам приходится заново создавать документацию и внедрять базовые процессы в работу команды.
Привет, Хаброжители! Популярность Python продолжает расти, а значит, проекты, созданные на этом языке программирования, становятся все масштабнее и сложнее. Многие разработчики проявляют интерес к высокоуровневым паттернам проектирования, таким как чистая и событийно-управляемая архитектура и паттерны предметно-ориентированного проектирования (DDD). Но их адаптация под Python не всегда очевидна.
Данный проект рассматривается как pet-project. Любую критику и советы готов увидеть в комментариях.
Это моя фактически первая статья на хабре за долгое время, последняя была написана очень много лет назад, если что-то не так - напишите в личные сообщения - я все исправлю.
Репозиторий с исходным кодом: https://github.com/theartofdevel/notes_system
Видео версия: https://www.youtube.com/watch?v=Txi95RQPRP0
Под катом текстовая расшифровка.
Меня зовут Александр, я руковожу backend-разработкой в КТS. Сегодня расскажу, как написать асинхронный краулер.
Такая задача часто встречается на практике, когда нужно реализовать периодическую синхронизацию/обкачку между сервисами.
Статья написана по мотивам вебинара, который мы провели в рамках нового курса «Асинхронное программирование на Python для начинающих». Курс стартует 18 октября, поэтому, если вам интересно — загляните посмотреть.
Что будет в статье:
1. Цель
2. Исходный код
3. Планировщик
4. Задача для краулера
5. Пробный запуск
6. Промежуточный итог
7. Функции put и join
8. Semaphore
9. Остановка фонового планировщика
10. Работа краулера на примере обкачки нашего блога на Хабре
11. Заключение
Всем привет! Добро пожаловать на презентацию об immutable infrastructure – достигая недостижимого идеала. Перед тем как мы начнем, хотел бы сделать небольшое вступление.
Геоаналитика с помощью Python: GeoPandas, folium, Uber H3, OSM + примеры как можно определять лучшие локации для поиска помещений под открытие кофейни (и не только).
Когда в пятый раз у тебя появляется на работе падаван, которому надо все рассказать по нескольку раз, в какой-то момент приходит в голову светлая мысль все свои речи законспектировать, попутно хоть немного структурировав все это дело. Так что сия заметка о сontainerd для того, чтобы не повторяться в сотый раз. Возможно, кому-то еще это будет интересно, хотя тут все без рокет-сайнс.
Linux старается оптимизировать использование памяти, занимая свободное место кэшем. Если память никак не используется, то это память, потраченная впустую.
Кэш заполняется данными по мере работы системы и когда приложениям требуется память, ядро ищет среди страниц кэша блок подходящего размера, освобождает его и выделяет приложению.
В некоторых случаях этот процесс может влиять на производительность, поскольку освобождение кэша занимает больше времени, чем просто доступ к неиспользуемой оперативной памяти. Поэтому иногда можно наблюдать снижение производительности.
Причина этого исключительно в том, что оперативная память используется на полную мощность, и других симптомов, кроме случайного эпизодического увеличения задержек, может и не быть. Такая же картина может наблюдаться, если жесткий диск не справляется с чтением и записью. Влияние может быть и на такие компоненты операционной системы как сетевая карта / iptables / ebtables / iproute2 — вместо реальной причины вы видите проблемы в сетевой задержке. В этой статье обсудим это подробнее и посмотрим, как минимизировать воздействие на систему.
Привет, Хабр! Меня зовут Сергей, я работаю IT Head в компании Quadcode. Сегодня хотел бы рассказать о том, как я решил проблему с хранением паролей в открытом виде в коде одного из моих pet-проектов. Думаю, это знакомая для многих ситуация. Знакомая — и неприятная.
Сразу скажу, что когда я начинал работу над проектом, ничего страшного в этом не видел, меня все устраивало. Но когда настало время подключать к разработке проекта кого-то извне, стало понятно, что хранить пароли в открытом виде небезопасно (да и перед контрибьюторами будет немного стыдно за такие банальные вещи) — это проблема. Вариантов решения было несколько. Под катом — рассказ о том, какое решение я выбрал и что получилось в итоге.
Микросервисная архитектура звучит неплохо само по себе, но еще лучше — быстрый микросервис, который эффективно использует ресурсы сервера.
Я покажу, как последовательно применять к простому без затей микросервису методы ускорения его работы, попутно рассматривая плюсы и минусы каждого из них.
Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.
Инструкция по диагностике проблем в работе баз данных в случае аварии.
Привет. У каждого на работе иногда случаются «чёрные» дни. Для меня такими днями являются аварии в работе сервисов, приводящие к недоступности систем для конечных пользователей. По счастью, такое происходит нечасто, но каждый такой случай заставляет меня долго рефлексировать над вопросами «что мы сделали не так».
После одной из аварий я поймал себя на мысли, что диагностика причины недоступности сервиса заняла слишком много времени. Инженеры, задействованные в разрешении инцидента, действовали не совсем скоординированно: проверяли одни и те же гипотезы и тратили время на изучение совсем уж «фантастических» вариантов. В квалификации ребят никакого сомнения у меня нет, поэтому в рамках рефлексии я списываю это на стрессовую ситуацию аварии.
Чтобы в следующий раз диагностика и устранение причин аварии происходили быстрее, мы совместно с DevOps-инженером Алексеем Поповым решили написать «план эвакуации при пожаре»: пошаговую инструкцию, которую можно было бы использовать для быстрого исследования инцидента.
Последняя проблема касалась работы базы данных и взаимодействия web-приложения с базой. Поэтому инструкция касается диагностики именно базы данных. Также хочу отметить, что эта схема — не истина в последней инстанции, а всего лишь наш опыт, перенесенный на «бумагу». Мы намеренно не стали включать слишком «экзотические» причины аварии, поскольку схема становится слишком громоздкой и нечитаемой.
Я буду признателен за комментарии и описания аналогичных проблем, которые происходили у вас.
В этом блоге я расскажу, как создать свой первый модуль Ansible.
Конечно, есть документация, доступная и на Ansible.com, но разобраться в ней достаточно трудно. Запуск своего первого модуля на основе этого введения дался мне с большим трудом. Вот почему я создал это пошаговое руководство. Новые пользователи заслуживают лучшей отправной точки.
