Рубрика «Серверное администрирование» - 32

Подготовка приложения для Istio - 1

Istio — это удобный инструмент для соединения, защиты и мониторинга распределенных приложений. В Istio используются разные технологии для масштабного запуска ПО и управления им, включая контейнеры для упаковки кода приложения и зависимостей для развертывания и Kubernetes — для управления этими контейнерами. Поэтому для работы с Istio вы должны знать, как приложение с несколькими сервисами на основе этих технологий работает без Istio. Если эти инструменты и понятия вам уже знакомы, смело пропускайте это руководство и переходите прямо к разделу Установка Istio на Google Kubernetes Engine (GKE) или установке расширения Istio on GKE.

Это пошаговое руководство, где мы рассмотрим весь процесс от исходного кода до контейнера на GKE, чтобы вы получили базовое представление об этих технологиях на примере. Также вы увидите, как Istio использует возможности этих технологий. Предполагается, что вы не знаете ничего о контейнерах, Kubernetes, service mesh или Istio.

Читать полностью »

Привет! Предлагаю вашему вниманию перевод поста: Миграция с Nginx на Envoy Proxy.

Envoy — это высокопроизводительный распределенный прокси-сервер (написанный на C++), предназначенный для отдельных сервисов и приложений, также это коммуникационная шина и «universal data plane», разработанный для больших микросервисных архитектур «service mesh». При его создании были учтены решения проблем, которые возникали при разработке таких серверов, как NGINX, HAProxy, аппаратных балансировщиков нагрузки и облачных балансировщиков нагрузки. Envoy работает вместе с каждым приложением и абстрагирует сеть, предоставляя общие функции независимо от платформы. Когда весь служебный трафик в инфраструктуре проходит через сетку Envoy, становится легко визуализировать проблемные области с помощью согласованной наблюдаемости, настройки общей производительности и добавления основных функций в определённом месте.

Возможности

  • Архитектура вне процесса: envoy — это автономный, высокопроизводительный сервер занимающий небольшой объем оперативной памяти. Он работает совместно с любым языком приложения или фреймворком.
  • Поддержка http/2 и grpc: envoy имеет первоклассную поддержку http/2 и grpc для входящих и исходящих соединений. Это прозрачный прокси от http/1.1 до http/2.
  • Расширенная балансировка нагрузки: envoy поддерживает расширенные функции балансировки нагрузки, включая автоматические повторные попытки, разрыв цепи, глобальное ограничение скорости, затенение запросов, локальную балансировку нагрузки зоны и т. д.
  • API для управления конфигурацией: envoy предоставляет надежный API для динамического управления своей конфигурацией.
  • Наблюдаемость: глубокая наблюдаемость трафика L7, встроенная поддержка распределенной трассировки и наблюдаемость mongodb, dynamodb и многих других приложений.

Читать полностью »

Хватит думать, что SLA вас спасет. Оно нужно, чтобы успокоить и создать ложное чувство безопасности - 1

SLA, оно же «service-level agreement» —соглашение-гарантия между заказчиком и поставщиком услуг о том, что получит клиент в плане обслуживания. Также в нем оговариваются компенсации в случае простоев по вине поставщика и так далее. По сути SLA — это верительная грамота, с помощью которой дата-центр или хостинг-провайдер убеждает потенциального клиента в том, что он будет всячески обласкан и вообще. Вопрос в том, что в SLA можно написать все что угодно, да и события, прописанные в этом документе, наступают не слишком часто. SLA — это далеко не ориентир в подборе дата-центра и надеяться на него уж точно не стоит.

Все мы привыкли подписывать какие-то договоры, которые возлагают определенные обязательства. Не исключением является и SLA — обычно самый оторванный от реалий документ, который можно вообразить. Более бесполезен, наверное, только NDA в юрисдикциях, где понятия «коммерческой тайны» толком не существует. А вся проблема в том, что SLA никак не помогает клиенту в правильном выборе поставщика, а только пускает пыль в глаза.

Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.
Читать полностью »

Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.

Для чего нужны «золотые сигналы» мониторинга и SRE? - 1

Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.Читать полностью »

И снова ERROR 1040…

Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

Подключение MySQL после ошибки 1040: слишком много соединений - 1

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

Читать полностью »

Обеспечение отказоустойчивости хранилищ - 1

Всем привет! Недавно состоялся открытый вебинар «Обеспечение отказоустойчивости хранилищ». На нём рассмотрели, какие проблемы возникают при проектировании архитектур, почему выход из строя серверов — это не оправдание для падения сервера и как сокращать время простоя до минимума. Вебинар провёл Иван Ремень, руководитель направления серверной разработки в «Ситимобил» и преподаватель курса «Архитектор высоких нагрузок».


Читать полностью »

Спустя 140 дней после выхода Red Hat Enterprise Linux 8, стала доступна для загрузки CentOS 8.
Ссылка на загрузку пока недоступна из соответствующего раздела сайта centos.org, но файлы дистрибутива уже размещены на зеркалах. Информация о выходе нового релиза так же зафиксирована в WikipediaЧитать полностью »

В 2016 году мы публиковали переводную статью «Полное руководство по веб-консолям 2016: cPanel, Plesk, ISPmanager и другие». Настало время обновить информацию об этих 17 панелях управления. Читайте краткие описания самих панелей и их новых функций.

Что нового в веб-консолях 2019 - 1

Читать полностью »

Недавно я решил поэкспериментировать с API на нашем сайте CardGames.io и попробовать фреймворк Serverless. Последние несколько лет он стал горячей темой в мире технологий, а я прокрастинировал хотел поддерживать технические навыки в актуальном состоянии и попробовать что-то новое. Поэтому решил потратить несколько часов на изучение Serverless и посмотреть, есть ли смысл в таком размещении API.

Текущая конфигурация

CardGames.io работает на AWS. Все html-страницы, CSS, JavaScript и изображения хранятся на S3. У нас есть API на C#, размещённый на Elastic Beanstalk, он работает на серверах Linux под управлением .NET Core с Docker. Наконец, мы используем CloudFront CDN перед статикой на S3 и API. Ниже приведён счёт EC2 за август 2019 года. У нас есть несколько других инстансов, но API работают на m1.small (да, вероятно, t2.small лучше подходит) с классической балансировкой нагрузки. Если суммировать выделенное красным, то выходит $164,21 в месяц, неплохо. Я даже включил туда EBS, поскольку не уверен, как разбить эти расходы, у нас ведь несколько проектов на EC2.
Читать полностью »

Даже странно, что про Laragon нет ни единой публикации на Хабре. Хочу очень кратко восполнить этот пробел, ибо данный инструмент вполне заслуживает популярности среди целевой аудитории веб-разработчиков, кодящих под Windows.

Laragon

Laragon — это простой и компактный WAMP (Apache + MySQL + PHP под Windows) во многом сродни своим более известным аналогам, вроде XAMPP, OpenServer, Denwer etc. Но, со своей маленькой изюминкой:

Когда вы создаете папку your-test-project в каталоге <laragon_root>www, то содержимое этой папки автоматически становится доступно из браузера по адресу http://your-test-project.test причем, шаблон, по которому именуются домены, также настраиваемый.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js