Администрирование

Давным-давно, такие слова как "hot keys" и "keyboard shortcuts" мне не всегда удавалось перевести на русский без потери лица. Как-то раз, я написал "клавиатурные сокращения", чем сразу же привлёк косые взгляды и вызвал смелые медицинские фантазии... Но вроде бы сейчас принято везде говорить и писать "горячие клавиши". О них и поговорим.

Данная заметка — шпаргалка по линуксовой оболочке Bash. Если вам приходится часто иметь дело с терминалом в Linux (и вы не меняли Bash на другой шелл), то будет очень полезно использовать эти самые "сокращения" на благо себе и в мирных целях. Текст написан для начинающих пользователей, но кто знает — может быть и вы найдёте в нём что-то новое и полезное для себя.

Для удобства будем считать, что по умолчанию под терминалом мы понимаем стандартную в настольной редакции Ubuntu программу "Терминал Gnome".

Привет, Хабр!

Деплоймент приложений в мультикластерной среде Kubernetes — одна из самых актуальных тем. Подход позволяет расширить возможности для масштабирования сервисов, обеспечить локальность трафика за счёт географического расположения кластеров, добиться роста надёжности и отказоустойчивости развёртываемого решения, а также исключить риски взаимного влияния приложений в рамках одного кластера. 

Вместе с тем управлять жизненным циклом подобных федеративных приложений довольно сложно. Под катом я предлагаю рассмотреть ключевые задачи в рамках создания федеративных сервисов и построить референсную архитектуру мультикластерного деплоймента, которую можно имплементировать в разных облачных инфраструктурах.

Строим архитектуру мультикластерного сервиса

Для иллюстрации мультикластерного подхода мы будем использовать простую систему, которая состоит из двух приложений. APP 1 обрабатывает внешний трафик от пользователей данной системы и в свою очередь вызывает APP 2 для обработки запросов, например, сохранения информации в базе данных.

В предыдущих частях я сделал приложения, которое работает с БД, GitHub API. Все компоненты разворачиваются при помощи AWS SAM. Можно запускать реализованные функции локально. Все функции собраны воедино в одно API:

Первые шаги. Первая лямбда (Часть 1)

Разворачиваем БД (Часть 2)

Как подружиться с БД (Часть 3)

Создаем REST API (Часть 4)

В этой, последней части, я рассмотрю вопросы, без ответов на которые опытная эксплуатация вряд ли будет похожа на прогулку в парке.

Уже изучено достаточно много, чтобы начинать собирать свой чемоданчик must have инструментов для serverless разработки. В этой части я соберу свой чемоданчик, а вы оставляйте в комментариях свои, будет интересно.

Мы в Smart Engines занимаемся разработкой систем распознавания документов уже более 7 лет, предоставляя нашим клиентам уникальные алгоритмы, «завернутые» в локальные (on-premises) безопасные программные библиотеки, предназначенные для встраивания в клиентские информационные системы. Несмотря на то, что наш SDK крайне прост по части интеграции, предоставляет простое и эффективное API распознавания документов под разные языки программирования (включая даже Wasm), нас постоянно спрашивают о наличии у нас сервиса распознавания с WebAPI. В сегодняшней статье мы вам расскажем, почему же до сих пор мы не сделали такой веб-сервис. И даже не планируем его в обозримом будущем.

Настройка LEMP-сервера с помощью docker для простых проектов. Часть третья: docker-compose, Dockerfile.

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Dockerfile, docker-compose и как поднять полноценный веб-сервер с помощью docker. Отмечу, что если вы являетесь опытным администратором, можете смело пропускать данный материал. Эта статья призвана простыми словами объяснить, что такое контейнеры, виртуализация и все, что с этим связанно.

trdl (сокр. от “true delivery”) обеспечивает безопасный канал доставки обновлений от Git-репозитория до хоста пользователя. В состав trdl входят три ключевых компонента, которые помогают защищать систему обновления от потенциальных атак: HashiCorp Vault, TUF-репозиторий и Git.

Расскажем, как работает решение, от каких минусов существующих систем обновления избавлено и как начать им пользоваться.

Привет Хабр! Последняя статья про инструменты для профилирования php датируется аж  2018 годом. Но все перечисленные решения разработаны много лет назад и имеют недостатки: древний интерфейс btp (аналог pinba), оверхед xhprof и необходимость ручного запуска phpspy на stage.

Я тимлид в рекомендательном сервисе Zoon и перед моей командой стояла цель найти инструменты, которые профилируют весь код на проде 24/7 и хранят данные. Инструменты, с которыми могут работать рядовые разработчики, без доступа к проду. Инструменты, которые позволяют находить "бутылочные горлышки" за 30 секунд.

В конце 2021 года показался свет в конце туннеля, в виде системы на основе семплирующего eBFP профайлера: prodfiler. 

С какими трудностями мы столкнулись при настройке и что вышло в итоге - под катом.

Рассказываем о том, как автоматизировать процессы онбординга и развёртывания инфраструктуры в iOS проекте с помощью Ansible.

Четыре года назад я уже писал статью на тему обработки кардиограммы. Тогда я показал, как можно перевести бумажную кардиограмму в цифровой формат PCM данных, отрыв затем её в звуковом редакторе. Мне было интересно воспроизвести, послушать и оценить, как это будет звучать. В этот раз предстоит не менее интересная задача. Необходимо разобраться в структуре файла кардиограммы, переписанного с цифрового кардиографа, и извлечь из него всю информацию о кардиограмме в понятном для пользователя виде.

В предыдущей статье, где рассказывалось о признании моего почтового сервера «недружественным», я упоминал о том, что смог обойти введённые ограничения с помощью аренды дополнительного виртуального сервера на территории РФ и проброса до него VPN-туннеля от основного сервера. После публикации статьи мне пришло несколько личных сообщений с просьбой рассказать подробнее о процессе настройки такого туннеля. В этой статье я постараюсь как можно более подробно описать этот процесс.

Децентрализация, как первичная форма Интернет-коммуникаций в целом, появлялась на фоне академических исследований [1, с.70], повлекших за собой глобальное развитие информационных технологий. Первичная система представляла собой не только внешний прогресс, относительно себя, но и имманентную эволюцию, выявляя в своей реализации отрицательные стороны и внутренние противоречия. Фактором её дальнейшего развития и одновременно гибели стала проблема масштабируемости связей. Невозможность в построении широковещательных и широкомасштабных соединений повлекли за собой потребность в промежуточных узлах, основаниях концентрации линий связи, тем самым, зародив ядро централизации, как точку отчёта дальнейшей проблематики.

Все помнят цепочки сертификатов и условия соблюдения доверительных отношений. Будем говорить об этом.

Сегодня прилетела одна “очень интересная задача”. Пользователям понадобился сайт: https://fgiscs.minstroyrf.ru/ - какой-то там ФГИС ЦС.

Поскольку сертификат недоверенный, то был послан Google Chrome следом за кораблём. Сертификат недоверенный, буржуйский фаервол шлёт туда же, да и отечественный Касперский не пускает.

Поехали копать сертификаты.

Поговорим про DPI? В России эту аббревиатуру большинство интернет-пользователей воспринимает негативно, так как она ассоциируется с блокировкой Телеграма – по мнению многих, одного из самых юзер-френдли мессенджеров. В 2018 году это событие вызвало широкий общественный резонанс. Конечно, DPI позволяет блокировать приложения, будь то мессенджеры, соцсети, да и вообще любой сервис в сети, однако сценариев применения операторами DPI гораздо больше.

Привет! Меня зовут Иван Гаас, я руковожу автоматизацией процессов разработки в Почтатехе — компании, создающей цифровые продукты для Почты России.

Среднее количество сообщений, которые мы обрабатываем в Почте — от 500 тысяч до миллиона в секунду. В пики, когда наша big data прогоняет свои 25 петабайт данных — до 3 миллионов. При этом кластер Kafka состоит всего из 12 серверов в каждом из 3 дата-центров и справляется с этим.

C 2016 года мы в три раза увеличили количество новых цифровых сервисов. Корпоративная шина на Kafka помогла быстро масштабироваться: количество интеграций за последнее время упало с 1000 до 300 и теперь растёт незначительно. Если раньше интеграция сервиса растягивалась на месяцы, то теперь достаточно нескольких дней.

Я расскажу, как мы построили шину, которая обеспечивает такую производительность.