User
Привет!
На связи Ваня Гулаков, DevOps из CloudMTS. Сегодня хочу рассказать про контейнерные ОС и как мы искали для сервиса Managed Kubernetes ту самую.
До недавнего времени мы использовали дедушку CentOS 7, который уже давно отжил свое. Основные причины переезда, соответственно, старое ядро и отсутствие поддержки.
Раз уж переезд был неизбежен, появилась мысль присмотреться к так называемым Linux For Containers или Container Optimized OS дистрибутивам.
Прим. переводчика: автор статьи рассказывает о преимуществах и недостатках QUIC, сравнивает его с TCP и пытается разобраться в причинах сравнительно низкой распространенности протокола.
Существует распространенное мнение, что транспортный протокол QUIC (RFC 9000) — просто очередное расширение оригинального транспортного протокола TCP (см. RFC 9293 и RFC 793). С этим мнением трудно согласиться. Я рассматриваю QUIC как значительный сдвиг в наборе транспортных возможностей, доступных приложениям при обеспечении конфиденциальности связи, целостности управления сеансами и гибкости.
«Если бы WASM+WASI существовали в 2008 году, нам бы не пришлось создавать Docker. WebAssembly на сервере — будущее компьютерных технологий», — считает Соломон Хайкс, соучредитель корпорации Docker и автор Docker Open Source Initiative.
Сравнительно недавно Docker объявил о поддержке WebAssembly на базе WasmEdge. А мы перевели фундаментальный, но практичный материал о том, как пользоваться этой технологией в экосистеме Docker и чем Wasm-контейнер отличается от классического.
Приступая к работе в ЦОД, можно легко запутаться в различных типах кабелей, которые используются для соединения и подключения сетевых устройств и серверов. Некоторые из них распространены и в повседневной жизни, а потому хорошо узнаваемы – Ethernet-кабели (с коннекторами RJ-45) и кабели питания (например, с распространенными вилками C13). Но другие, такие как оптические кабели с коннекторами стандарта SFP, LC, SC, силовые с вилкой типа IEC-309 и т. д., известны не так широко.
Если вы проводите какие-либо работы непосредственно в стойке, любая ошибка может стоить дорого – нажата не та кнопка, и клиенты уже в дауне, а любимые и глубоко уважаемые специалисты техподдержки шлют вам тикеты счастья. Даже Uptime Institute в своем исследовании 2021 года отмечает, что в 79% случаев причиной падения серверов в ЦОДах является человеческий фактор. Всё надо делать вовремя – и нажимать кнопки, и менять комплектующие, и переключать кабели…
Так вот о кабелях. Чтобы начать с ними работать, было бы неплохо хотя бы знать, как они выглядят и какие функции выполняют.
Этот материал как раз об этом.
В первую очередь, он будет полезен в роли шпаргалки сотрудникам-стажерам, только начинающим работу с аппаратной частью ИТ-инфраструктуры.
Данная статья потенциально интересна тем, кто выбирает между managed и рукотворным k8s кластерами в облачной платформе, а также тем, кто просто хочет почитать о некоторых болях и провалах, случающихся при поддержке собственноручно развернутых k8s кластеров.
Создание кластера Kubernetes может быть сложным процессом, который включает в себя множество опций, но сложные вещи могут стать более понятными, когда их разложить на части. В этой статье мы демистифицируем процесс создания кластера Kubernetes, понимая минимальный набор компонентов и настроек, необходимых для запуска узла Kubernetes внутри виртуальной машины.
Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.
Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.
Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?
Привет всем, кому интересна ОС FreeBSD! После летне-отпускного отсутствия начинаю новый цикл статей. Надеюсь, будет занимательно и полезно.
Для тех, кто тут впервые, поясню, что являюсь разработчиком российского Интернет-шлюза Интернет Контроль Сервер, реализованного на базе FreeBSD. А потому, изнанка этой операционки, ее фишки и тонкости администрирования - то, с чем я сталкиваюсь ежедневно и делюсь с вами.
В предыдущей серии статей мы рассмотрели файрвол PF. Оценили возможности и настроили его для разных ролей. В новом цикле сделаем то же для файрвола IPFW. Как и с PF, начнем с краткого обзора и создания простой конфигурации для защиты веб сервера. В следующий статьях будем погружаться и усложнять конфигурацию постепенно, вводя новые типы правил и добавляя "мяса".
CJM часто воспринимают либо как красивое изображение, либо как очередной buzzword. Но так ли это на самом деле?
Costomer Journey Map - это карта взаимодействия пользователя с продуктом, карта составленная с учётом конкретных действий пользователей, с учетом его эмоций, целей, мотивов, привязки его к конкретному этапу, препятствий, барьеру пользователя. Визуализация его опыта.
no reply from osd.X. Немного slow requests и самопроизвольные рестарты, что для ceph не критическое событие и довольно частое. В общем, такое бывает. Но, к сожалению, не все перезапустившиеся osd смогли подняться. А именно пала героем osd.45 на storage6.
Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть).
В этой части мы обсуждаем инвентори. Я обещал ещё и переменные, но инвентори оказалась большой темой, так что посвящаем ей отдельную статью.
Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно.
Оглавление:
inventory_hostname vs ansible_hostansible_user — писать или не писать?В этой части мы перестаём говорить о простом и приятном и начинаем говорить о трудном. Переменные в Ansible: scope, precedence, рекурсивная интерполяция. Для тех, кто дочитает до конца, маленький бонус: упрощённая таблица приоритетов, с которой можно жить. Предыдущие части: 1, 2.
Обычно рассказ про переменные в Ансибл начинают с чего-то очень простенького, что создаёт у читателя иллюзию, что переменные в Ансибл — это как в любом другом языке программирования. Мутабельные или немутабельные, локальные и глобальные. Это не так.
Это не так.
У Ансибла возникла уникальная модель переменных (модель памяти?), которую надо учить с нуля. И рассматривать мы её начнём с того места, где значения используются (обычно переменные Ансибла рассматривают с того места, откуда они появляются). Почему? Потому что при рассказе в этом направлении у нас образуется направленный граф, который куда легче уложить в голову.
Обратите внимание — я сказал "значения", потому что "переменные" — это всего лишь имена к значениям. У переменных свой глубокий внутренний мир, и про него во второй части.
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".
A. Бесплатные веб-сайты