Что такое ретроградный Меркурий и почему он никак не влияет на вашу судьбу


Одной из величайших загадок XVI века был вопрос с видимым ретроградным движением планет. Объяснения давали как геоцентрическая модель Птолемея (слева), так и гелиоцентрическая модель Коперника (справа). Однако для полного уточнения этого вопроса потребовались теоретические прорывы в понимании законов, лежащих в основе наблюдаемых явлений. В итоге Кеплер открыл свои законы, а Ньютон описал закон всемирного тяготения.

Меркурий становится ретроградным – то есть, меняет направление своего движения по небесной сфере – 3-4 раза в год. Последний раз он проделал это 9 сентября 2022 года. Такое его поведение известно с античных времён, и сначала его неправильно объясняли через теорию эпициклов от Птолемея. Сегодня же мы лучше понимаем гравитацию и то, как объекты двигаются в рамках Солнечной системы. Почему же именно Меркурий ведёт себя так?

Практически весь год наблюдатель на Земле может видеть движение планет по небу, и происходит оно довольно предсказуемо. Если звёзды для наблюдателя остаются неподвижными относительно друг друга, то планеты – будучи гораздо ближе к нам, чем звёзды – ночь от ночи сдвигаются на небе. Большую часть времени эти далёкие миры медленно двигаются в одну и ту же сторону – обычно с запада на восток, причём каждый день их восход и закат происходит всё позже и позже.

Но иногда, если вы будете отслеживать движение каждой из планет постоянно и долго, несколько недель или месяцев, вы заметите, что планета начнёт двигаться медленнее, а потом вообще остановится. После этого на несколько недель она поменяет направление своего движения – это будет т.н. ретроградный период. Наконец это движение вновь замедлится, его направление снова поменяется, и планета снова пойдёт в ту сторону, куда двигалась до этого. Ретроградные периоды обладают своими особенностями для каждой из планет, при этом у Меркурия они самые короткие и самые частые.

Когда большинство планет Солнечной системы входят в ретроградный период – включая Марс, Юпитер, Сатурн, Уран и Нептун – это происходит потому, что Земля «нагоняет» их на орбитах. У орбиты каждой из планет, движущихся вокруг Солнца, есть свои особенности – среднее расстояние до светила и средняя орбитальная скорость. Быстрее всего движутся самые близкие к Солнцу планеты, а медленнее – самые далёкие.

Земля находится на среднем расстоянии в 150 млн км от Солнца и большую часть года движется по орбите со скоростью 30 км/с. Меркурий и Венера расположены ближе и двигаются быстрее. Среднее расстояние от Меркурия до Солнца – 58 млн км, скорость – 47 км/с. Все внешние планеты расположены дальше и двигаются медленнее. Нептун расположен на расстоянии в 4,5 млрд км и движется со скоростью в 5 км/с. На полный оборот по орбите у Нептуна уходит более 160 земных лет. Меркурий же успевает более четырёх раз пробежать вокруг Солнца, пока Земля делает один оборот.

Одной из наиболее гениальных геометрических идей истории было осознание того, что для возникновения ретроградного движения, наблюдаемого с Земли, планете вовсе не нужно физически менять траекторию движения, его скорость или направление. Всё это можно объяснить при помощи простой гелиоцентрической модели. Возьмём для примера Землю и Марс. Марс находится дальше от Солнца и медленнее движется по орбите. Соответственно, Земля совершает один оборот за меньшее время. В итоге, когда Земля проходит между Солнцем и Марсом, она его «обгоняет».

Обгон планеты для нас будет выглядеть так же, как обгон на шоссе автомобиля – с нашей точки зрения планета будет двигаться «назад», хотя на самом деле все мы движемся вперёд, просто другая планета делает это медленнее. Поскольку Земля двигается по космосу быстрее Марса и примерно в том же направлении, кажется, что Марс меняет нормальное направление движения с запада на восток на противоположное, и начинает двигаться с востока на запад относительно неподвижных звёзд. И только после пары месяцев ретроградного движения Марс возобновляет привычное перемещение, когда Земля движется по примерно перпендикулярному вектору.

Подобная схема работает для всех внешних планет. Чем дальше планета, тем сильнее эффект. Если скорость движения Марса сравнима с Земной, то Сатурн, Уран и Нептун движутся гораздо медленнее, поэтому их движение по нашей небесной сфере почти полностью определяется тем, как Земля движется по Солнечной системе. Каждый раз, когда Земля проходит между более удалённой планетой и Солнцем, видимое движение этой планеты по нашему небосводу меняется с обычного (с запада на восток) на ретроградное (с востока на запад). Потом в какой-то момент, когда Земля, пройдя по орбите, начинает двигаться в другом направлении, внешняя планета вновь начинает обычное движение по небу.

Со внутренними планетами, Венерой и Меркурием, всё происходит наоборот. Они двигаются по орбитам быстрее Земли, а их орбиты меньше нашей. Большую часть времени Меркурий и Венера двигаются с востока на запад, постепенно превращаясь из утренних звёзд (видимых в небе до рассвета) в вечерние (видимые после заката).


Симуляция движения планет Солнечной системы за один земной год. Видно, как Меркурий перегоняет Землю на орбите три раза за год. Период обращения Меркурия составляет всего 88 дней, поэтому у него бывает 3-4 ретроградных периода за год – это единственная планета, у которой таких периодов в год больше одного. Другие планеты начинают ретроградное движение только когда их обгоняет Земля – примерно раз в год для всех планет, кроме Марса, у которого это бывает реже.

Однако в какой-то определённый момент – в последний раз с Меркурием такое случилось 9 сентября 2022 года – внутренняя планета входит в период максимальной элонгации в небе после заката, когда она находится в дальней от Солнца точке, к западу от него. Через непродолжительное время, в данном случае – пару недель, внутренняя планета переходит на ретроградное движение, с запада на восток. Только у Венеры и Меркурия ретроградное движение связано с перемещением по небу с запада на восток.

Эти ретроградные периоды соответствуют той части орбит Венеры и Меркурия, где эти внутренние планеты движутся между Солнцем и Землёй, и обгоняют нас. Случается это тогда, когда у внутренней планеты компонент скорости, направленной в ту же сторону, что и наша скорость, оказывается выше, чем у Земли, и длится это всего несколько недель. Меркурий начал свой ретроградный период 9 сентября и закончил 1 октября.

Когда внутренняя планета обгоняет Землю, она начинает «заворачивать», обходя Солнце вокруг, и ретроградный период заканчивается, когда её компонента скорости по направлению движения Земли становится меньше, чем у Земли. При этом элонгация планеты будет ещё какое-то время увеличиваться. Хотя ретроградный период Меркурия начался 9 сентября, максимальной элонгации он достиг 27 августа. И наоборот, хотя его ретроградный период закончился 1 октября, максимальной восточной элонгации, видимой в утреннем небе, он достиг 8 октября.

У Меркурия, который завершает полный оборот вокруг Солнца всего за 88 дней (примерно за четверть земного года), часто и регулярно случаются другие ретроградные периоды. Следующий ретроградный период Меркурия начнётся в январе 2023 года, потом в мае, потом в сентябре и потом в декабре 2023. В любой год обычно укладываются 3-4 ретроградных периода Меркурия – у других планет такое случается обычно только по разу в год, а у Марса иногда и реже.

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

Будущие нижние соединения Меркурия ожидаются 7 января, 1 мая, 6 сентября и 22 декабря 2023 года. Но транзитов по диску Солнца там не будет. Последний транзит Меркурия был 11 ноября 2019 года, а следующий будет только в 2032 году. Из-за того, что Меркурий расположен близко к Солнцу, быстро движется по орбите, а плоскость его орбиты не сильно отличается от нашей, транзиты Меркурия случаются чаще, чем транзиты Венеры.

Венера находится почти в два раза дальше от Солнца, чем Меркурий, плоскость её орбиты наклонена сильнее, а нижнее соединение с Землёй у неё происходит раз в 19 месяцев — а не раз в 3-4 месяца, как у Меркурия.

Одно из прохождений Венеры случилось 6 июня 1761 года, и поскольку оно было вычислено заранее, за ним наблюдали десятки учёных XVIII века, среди которых был и Михаил Васильевич Ломоносов. Наблюдая за эффектами, видимыми во время прохождения, Ломоносов увидел некое размытие контуров планеты и верно истолковал его, как следствие преломления солнечного света в атмосфере Венеры, не уступающей по величине атмосфере Земли. Впоследствии эффект был назван «явлением Ломоносова».

В наше время последний транзит Венеры по диску Солнца случился с 5 на 6 июня 2012 года, а следующий ожидается лишь с 10 на 11 декабря 2117! Средний человек может увидеть лишь два транзита Венеры за всю жизнь, и если вы пропустили транзиты 2004 и 2012 года, вам придётся очень хорошо следить за своим здоровьем, чтобы дожить до следующего.

Во время своих ретроградных периодов Меркурий подходит к Земле ближе всего, и соответственно гравитационно воздействует на неё сильнее, чем в другие периоды. Во время следующего нижнего соединения Меркурий подойдёт на 96 млн км к Земле, однако некоторые соединения могут сокращать это расстояние до минимальных 82 млн км – последний раз такое было в 2015-м. Кроме того, хотя Меркурий и является самой малой планетой Солнечной системы, он может иметь видимый размер в 10 угловых секунд, т.е. в 1/6 угловой минуты (угловая минута составляет 1/60 градуса).

Это всё очень интересно, однако влияние Меркурия на Землю во время ретроградного движения и даже во время нижнего соединения практически невозможно засечь. Как Земля вызывает прецессию орбиты Меркурия, так и Меркурий вызывает прецессию орбиты Земли. К сожалению (или к счастью) эта прецессия меняет орбиту меньше, чем на одну угловую секунду в год, что практически невозможно заметить. Засветки неба Меркурий тоже никакой не даёт, а приливное действие Меркурия меньше, чем у Луны в миллион раз. Так что Меркурий, будь он ретроградным или каким-либо ещё, практически никак не может повлиять на жизнь на Земле – по крайней мере, так, как мы можем измерить.

Однако явление это интересное и абсолютно реальное. Из всех планет Солнечной системы лишь Меркурий становится ретроградным по нескольку раз в год, и обычно это бывает 3-4 раза. Внутренние планеты обычно движутся в небе Земли с востока на запад, а внешние – с запада на восток. В ретроградные периоды всё наоборот – Марс, Юпитер, Сатурн, Уран и Нептун движутся с востока на запад, а Меркурий с запада на восток.

Большинство людей, говоря о ретроградном Меркурии, подразумевают астрологию – они интересуются и беспокоятся о том, как это может повлиять на их жизнь на Земле. Неизвестно, является ли подобное воспринимаемое людьми влияние чем-то большим, чем просто склонностью наблюдателя к подтверждению своей точки зрения, однако астрофизика позволяет нам чётко описать влияние планеты на нашу жизнь – визуально, гравитационно и в связи с приливами. И это влияние практически неразличимо. Но по крайней мере, если теперь вы увидите ретроградное движение Меркурия в ночном небе, вы будете точно знать, отчего это происходит.


ссылка на оригинал статьи https://habr.com/ru/post/708508/

Сертификаты Let’s Encrypt и ACME вообще во внутренней сети

Обычно внутри корпоративной сети нынче полно всяких приложений, и хотелось бы чтобы они работали по SSL. Можно, конечно, поднять свой УЦ, раздать сертификаты, прописать пользователям свой корневой сертификат — и это будет работать. А можно просто воспользоваться сервисом Let’s Encrypt, раздав его сертификаты своим внутренним серверам, которые не видны из Интернета, причем сделать это просто и с минимумом трудозатрат на поддержку.

Необходимые условия

  • Наличие зарегистрированного домена, допустим, mycompany.ru и адресация внутренних серверов в нем.

  • Использование split-DNS, т.е. разрешение доменных имен mycompany.ru в разные IP адреса для внутренней сети и для всего Интернета. Делается либо через механизм View сервера BIND либо просто путем использования разных DNS серверов.

  • Внутренние сервера имеют доступ в Интернет по HTTPS — через маскирующий/NAT шлюз, файрвол, прокси, как угодно. Впрочем, это можно преодолеть, просто эту статью придется дочитать до конца, а поработать чуть больше.

Как это работает

Логика работы сервиса Let’s Encrypt:

  • Сервер-претендент обращается к API Let’s Encrypt по HTTPS, сообщает ему домены, для которых нужен сертификат. Например, server.mycompany.ru.

  • В ответ сервис формирует некий код, который должен быть размещен по запрошенному доменному адресу чтобы подтвердить принадлежность домена. Есть варианты: размещение файла с кодом на веб-сервере или добавление в DNS домена определенной записи. Мы будем использовать файл на веб-сервере.

  • «Проверялка» Let’s Encrypt лезет простым GET запросом на адрес http://server.mycompany.ru/.well-known/acme-challenge/{а здесь сам код}, и если получает ожидаемый ответ — то считает, что домен проверен.

  • Let’s Encrypt выпускает сертификат и предоставляет его серверу.

На самом деле все немного сложнее, но нам детали и не потребуются.

Что мы делаем и зачем

Нам понадобится один прокси-сервер (nginx) и правильная настройка DNS. Больше, удивительным образом, ничего. Прокси-сервер должен быть доступен из Интернет и иметь доступ во внутреннюю сеть (dual-homed).

Полагаем, что все наши сервера во внутреннем DNS прописаны по именам. Во внешнем DNS, в зоне mycompany.ru задаем имя для внешнего адреса прокси-сервера, пусть будет proxy. И там же для каждого сервера из внутренней сети делаем запись CNAME, указывающую на proxy.

Конфигурируем nginx, общая конфигурация самая обычная, нужные нам блоки server в контексте http выглядит так:

server {     listen       80;     server_name  .mycompany.ru;     # Принимаем любые имена в домене     location /.well-known {          if ($request_method != GET) { # Разрешаем только метод GET             return 444;               # иначе - сбрасываем TCP соединение         }         resolver 10.0.0.2 10.0.1.2; # Обязательно ипользуем внутренние DNS         proxy_pass http://$host;    # проксируется на сервер внутрь сети с тем же именем     }      location / {                    # Все остальные запросы -         return 444;                 # просто сбрасываем TCP соединение         log_not_found off;          # и ничего не пишем в лог         access_log off;     }  } server {                            # На все запросы по IP адресу без домена     listen       80 default_server; # отвечаем сбросом TCP соединения     server_name  _;     return 444;     log_not_found off;     access_log off; } 

Кстати, если у вас уже есть dual-homed сервер с nginx для каких-то других задач, то эту конфигурацию можно просто добавить к нему, она не будет мешать обслуживанию других серверов даже с именами в том же домене.

Работает это очень просто:

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

  • «Проверялка» Let’s Encrypt разрешает запрошенное имя в адрес proxy и посылает туда запрос GET, естественно доменное имя указано в запросе.

  • Получив запрос, прокси еще раз разрешает доменное имя, но уже внутренним DNS и выполняет запрос на реальный сервер, получает ответ и отдает его «проверялке».

  • Проверка пройдена, наш внутренний сервер получает сертификат.

Вуаля! Все работает! Ставим на внутреннем сервере Certbot или активируем встроенную поддержку сертификатов Let’s Encrypt у нужного нам софта — и погнали. Не забываем повесить задачу на автообновление сертификатов!

За, против и немного про безопасность

Преимущества:

  • Простота реализации. По плечу очень среднему админу.

  • Совместимость. Работают любые ACME-клиенты с проверкой по HTTP на всех платформах, в том числе родной Certbot, встроенные ACME клиенты (проверено на Proxmox), да и вообще нет ограничений по использованию ACME кроме верификации по HTTP. И да, работать должно не только с Let’s Encrypt.

  • Минимальные усилия на изменения: чтобы Let’s Encrypt стал доступен для любого сервера внутри — достаточно просто добавить CNAME для него во внешний DNS. Ну и сделать соответствующие ACME-настройки на самом сервере, конечно.

Недостатки:

  • Мы вроде как показываем имена внутренних серверов в Интернете. На самом деле — нет, если только внешний DNS настроен правильно и не позволяет кому попало забирать зону целиком, что является хорошей практикой независимо от целей.
    UPDATE: Как правильно заметил в комментарии @HxShard , используя публичные сертификаты внутри сети мы неизбежно делаем доступными доменные имена узлов, для которых мы их получили, как минимум таким вот образом https://crt.sh/?q=habr.com. Тут уж придется каждому решить — насколько большой риск тем самым создается. Лично я оцениваю его как весьма небольшую цену за удобство, во всяком случае вряд ли именно это станет самым низким участком моего виртуального забора.

  • Теоретически, прокси-сервер, как любой dual-homed, создает угрозу. Но и меры защиты — самые обычные. Если они непонятны и вы не можете правильно настроить защиту для Linux + Nginx — то вам вообще не стоит иметь дела с серверами, подключенными к Интернету. Позовите взрослых пожалуйста!

  • Опять же, теоретически, существует возможность DoS на внутренний сервер при условии что его имя получено — путем заваливания его запросами в каталог /.well-known. Крайне маловероятный сценарий, но его можно легко купировать, ограничив скорость запросов на прокси. Это же nginx!

  • Внутренние серверы должны иметь доступ в Интернет. Но если это для вас проблема — то ниже покажу как ее решить.

К сожалению, Let’s Encrypt не поддерживает и не публикует список собственных IP-адресов, поэтому ограничить обращение внутренних серверов наружу и запросы извне по IP — не получится.

И все же, изолированные сервера, сделаем?

Ценою усложнения схемы — сделаем и это. Дело в том, что ACME-клиент посылает запрос по HTTPs. С одной стороны — его тоже можно проксировать, но при этом «ломается» сертификат, и скорее всего ACME-клиент выдаст ошибку. SSL соединение нормально проксируется только на уровне TCP, но к счастью nginx и это умеет.

Нам понадобится:

  • По два внутренних IP адреса на каждый ACME сервис (для основного и staging).

  • «Перехватить» домен сервиса — либо путем записей в hosts либо на своем внутреннем DNS.

  • Настроить nginx для проксирования на уровне TCP.

Кстати: адреса API разных ACME-сервисов можно взять из скрипта acme.sh

Ок, делаем, на примере Let’s Encrypt. Будем считать, что для внутренних интерфейсов прокси выделены адреса 10.0.1.34 и 10.0.1.35.

Перехват DNS

Перехват через hosts проще, но его надо не забыть сделать на каждом внутреннем сервере, добавив в файл строки:

10.0.1.34 acme-v02.api.letsencrypt.org 10.0.1.35 acme-staging-v02.api.letsencrypt.org

Перехват внутренним DNS сервером сложнее, но зато сделать его надо один раз и работать он будет для всех серверов. Для этого на внутреннем DNS создаем зону api.letsencrypt.org, и заводим в ней нужные хосты, пример файла зоны для BIND:

;Перехват api.letsencrypt.org ; SOA api.letsencrypt.org.   3600     IN     SOA     localhost.      root.localhost. (                                                 2022122900                                                 28800                                                 7200                                                 604800                                                 3600                                                 ) ;основной сервер acme-v02                3600     IN     A      10.0.1.34  ;staging сервер acme-staging-v02        3600     IN     A      10.0.1.35

Вне зависимости от способа, проверяем результат пингуя с внутреннего сервера по именам acme-v02.api.letsencrypt.org и acme-staging-v02.api.letsencrypt.org, пинги должны проходить на .34 и .35 адреса соответственно. Значит, перехват DNS удался.

Настройка Nginx

Обратите внимание, что эти директивы должны находиться в контексте main, в то время как все привычные файлы конфигурации виртуальных хостов в каталоге «из коробки» уже находятся в контексте http. Поэтому надо либо добавлять в основной файл конфигурации /etc/nginx/nginx.conf, либо в каталог либо в отдельный файл и в правильном месте ставить include.

stream {     resolver 8.8.8.8; # А вот здесь нам нужен DNS, способный разрешать имена в Интернете      server { # Проксируем 443 порт на .34 адресе и отправляем на основной сервер          listen 10.0.1.34:443;         proxy_pass acme-v02.api.letsencrypt.org:443;     }      server { # Проксируем 443 порт на .35 адресе и отправляем на stageing сервер         listen 10.0.1.35:443;         proxy_pass acme-staging-v02.api.letsencrypt.org:443;     } }

Ну вот и все! Теперь и серверы внутренние доступа наружу не имеют и Let’s Encrypt на них работает.

P.S. Дед мой, добрая ему память, частенько говорил: «Кабы не клин да мох, да и плотник бы сдох!». Так и хочется перелицевать на «Кабы не nginx, да ???, так и сисадмин бы ???». Но вот что подставить? Предлагайте! )))


ссылка на оригинал статьи https://habr.com/ru/post/708510/

Праздник к нам приходит: новогодний сезон Kubernetes на Хабре

С 29 декабря 2022 до 24 февраля 2023 Хабр вместе с #CloudMTS запускает сезон Kubernetes — конкурс технических статей о K8s, оркестрации и управлении контейнерами. Это третий сезон Хабра: летом и осенью мы уже неслабо продвинули пачку крутейших хардкорных текстов о Java и Data Mining. Теперь пришла пора разобрать по косточкам Kubernetes и относящиеся к нему DevOps-практики.

Зачем это нужно

Максимальные просмотры на Хабре традиционно набирают универсальные материалы, понятные и полезные всем. А вот узкоспециальные и технически сложные статьи как правило получают меньше внимания: просто в силу того, что интересны не всем. И тут нет заговора — чисто тервер.

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

Что по призам и славе

  • Зал славы рок-н-ролла. Хабр выдаст всем авторам плашку «Участник сезона Kubernetes», а победителю достанется значок «Победитель сезона Kubernetes» и дополнительный инвайт.

  • Грант от спонсора на 30 000 рублей для подготовки ещё одной классной статьи получит победитель сезона. Если на новую статью нет времени, грант можно передать другому участнику — так было в сезоне Java.

  • MacBook от спонсора. Автору самой рейтинговой статьи достанется Apple MacBook Air — вот такой, как на картинке.

Правила сезона 

Почти такие же, как и раньше — но с поправкой на тему.

  • Побеждает пост с наивысшим рейтингом. Голосовать за лучшую статью можно на протяжении всего сезона, а после его завершения мы объявим результаты.

  • Один автор может прислать сколько угодно заявок. Чем больше статей, тем выше шанс привлечь внимание читателей и победить. Принимаются не только новые посты, но и старые тексты, опубликованные после 1 декабря 2022. Последний день приёма заявок — 24 февраля 2023.

  • Участвовать могут все — даже авторы из «Песочницы». Отличная возможность привлечь максимум внимания к вашему первому посту и сразу попасть «в основу».

  • Только технохардкор. Мы хотим глубокого погружения в технические, архитектурные и процессные детали, неожиданные решения и прочие межпланетные дела.

  • Kubernetes в центре внимания, а технологии важнее эмоций. Пост должен быть про применение Kubernetes, а не про DevOps-практики в целом или виртуализацию. Если опытный инженер или разработчик, имеющий дело с контейнерами, узнает из вашего поста что-то новое и полезное — это тот самый технохардкор.

  • Без лишней рекламы или антирекламы. Можно упоминать свою компанию, но не воевать с конкурентами или на всю катушку пиарить своё супер-пупер-решение. Заявки отсматриваем вручную, так что no pasaran.

Зачем продвигать именно статьи про Kubernetes

Вовремя попавшаяся статья с описанием технических подробностей системы или примерами решения сложных вопросов могут сэкономить кучу ресурсов разработки, времени и денег. Для примера мы собрали несколько кейсов из практики #CloudMTS: как ребята фиксили неполадки, творчески использовали операторы K8s и баг-репортили в Red Hat. Часть кейсов — из практики команды, которая работает над внутренней инфраструктурой, а часть — от команды внешнего продукта, Containerum Kubernetes Service (CKS).

История #1. Скрытые механики продукта, о которых лучше знать заранее

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

Итак, у нас есть департамент кибербезопасности, который разрабатывает систему по комплексному засекьюриванию кластеров. Эта система сканирует образы и запущенные контейнеры, мониторит трафик — в общем, делает всё, чтобы злоумышленники не могли нанести никакого вреда.

В один прекрасный момент мы заинсталлили это решение в свою DEV-среду для пробной обкатки. Пару дней всё прекрасно работало, однако потом у нас начали жутко течь по ресурсам мастер-ноды, при этом мы не вносили никакие изменения в конфигурацию самого кластера, да и профиль нагрузки от запущенных бизнесовых приложений особо не менялся. На графиках загрузки нод в Grafana не было каких-то характерных всплесков, нагрузка росла линейно, пока CPU и RAM машины не утилизировались почти под 100%. Основным виновником торжества был kube-apiserver, он поедал какое-то совершенно неадекватное количество ресурсов для кластера подобного размера.

Мы долго не могли понять, в чём дело, и почти случайно нашли в аудит-логах кластера, что у нас постоянно валятся validation-хуки: судя по записям, один из них циклически не мог обработать обращение к ресурсу pods/attach. Потом выяснилось, что этот хук связан с вышеупомянутой системой от департамента кибербезопасности. Начав копать дальше, мы обнаружили, что проблема связана с работой Docker-in-Docker-задачи в GitLab-раннере, который использовался для интеграционных тестов. Во время работы пайплайна раннер генерировал те самые обращения к ресурсу, по которым мы видели ошибку в логах.

Теперь паззл сложился: некоторое время баг никак не проявлял себя, так как сбойный ивент никто не триггерил. Но когда запустилось большое количество интеграционных тестов, раннеру с хуком поплохело. В итоге kube-api получил очередь задач, которую никак не мог адекватно разобрать и начал течь по ресурсам, а дальше поплохело уже и его соседям на ноде. На машины, которым повезло меньше, приходил ещё и OOM, что добавляло дополнительных проблем с доступностью кластера.

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

История #2. Для Kubernetes можно найти много интересных применений

Типовые паттерны работы с привычными инструментами — это хорошо и правильно, но всегда можно попытаться выйти за рамки привычного использования решений и задействовать их каким-то хитрым способом. Мы любим и читать про такие хаки, и придумывать их. Вот вам небольшая, но гордая история:)

Весь Kubernetes работает на событийной модели, то есть он сам автоматически постоянно приводит состояние отдельных компонентов к тому состоянию, которое описано в манифесте. На этой же модели строятся и все операторы, дополнительные контроллеры для K8s, которые используют собственные API — CRD (Custom Resource Definition) — чтобы хранить собственные спеки CR (Custom Resource) и на их основе создавать новые ресурсы в кластере или управлять жизненным циклом существующих.

И мы подумали: а почему бы не воспользоваться таким чудесным инструментом для унификации обслуживания всего и вся и перевести всё на готовые операторы? Дело в том, что у нас была проблема: часть инфраструктуры находится вне Kubernetes, и тащить её туда мы не хотим по ряду причин. Однако управлять ею с помощью K8s тоже хочется, так как это сразу даёт ряд преимуществ:

  • Автоматическое и непрерывное приведение инфраструктуры к необходимому виду. В отличие от стандартных IaC-подходов в таком случае нам не нужно, чтобы кто-то нажимал на кнопочку деплоя.

  • Единая точка правды: статусы всех интересующих нас подконтрольных сущностей мы можем посмотреть в одном месте, не бегая по куче ВМ, клиентов, Git-репозиториев.

  • Благодаря единой точке правды мы можем легко и быстро делать бэкапы нашего K8s (etcd-снапшоты) и так же легко восстанавливаться из них. А ещё после восстановления операторы в K8s самостоятельно настроят все необходимые сущности вовне, и нам не придётся дополнительно что-то запускать из других мест.

Подумав, мы сами написали несколько операторов для закрытия всех своих потребностей:

  • Создание индекс-паттернов для Kibana.

  • Создание записей в нашем DNS (External DNS нам не подошёл, потому что он не умеет работать с тем сервером, который используем мы).

  • Управление Kafka: создание пользователей, топиков, настройка ACL и так далее.

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

История #3. Рассказы о рабочих моментах помогают избегать ошибок

Хорошее тестирование помогает не только проверить корректность решения, но и, эмулируя поведение клиента, попытаться выстрелить себе в ногу с помощью доступных в админке средств. Такие кейсы, конечно, редкость — в открытом доступе их практически не найти, потому что они могут касаться деталей реализации продукта. И тем выше их ценность: зная подобные нюансы, можно изначально учесть их в архитектуре своего решения. Рассказываем, как мы успешно обрушили один из кластеров в Containerum Kubernetes Service:)

В Kubernetes есть сущности, которые отвечают за проброс трафика извне внутрь. Эти сервисные сущности бывают трёх типов: кластер IP, нод-порт и load balancer — и собираются они как матрёшка, от самой маленькой до самой большой. Под них выделяются CIDR-диапазоны IP-адресов, которые не должны пересекаться с диапазонами адресов, зарезервированных для подов и сервисов K8s-кластера, сетей, в которых находятся виртуальные машины, сервера и т. п.

В процессе разработки мы решили попробовать поломать систему — и нам это удалось. Мы создали сервис, в externalIPs которого указали адрес одной из рабочих нод. На всех узлах кластера создались IPVS-маршруты, которые перенаправляли трафик с заданного пользователем IP-адреса на те ноды, где запущены поды, принимающие трафик с сервиса.

При попытке определить MAC-адрес ноды, которым воспользовался пользователь, мы периодически получали адреса с соседних нод. В итоге эта worker-нода не могла нормально взаимодействовать с kube-apiserver, а при попытке зайти на неё по SSH мы каждый раз попадали на случайную виртуальную машину, входящую в кластер.

В общем, новый сервис был благополучно растиражирован по всему кластеру с единым адресом. И кластер, естественно, начал сходить с ума: он пытается отправлять запросы, а они приходят на случайные машины (адрес-то во всех используется один). В итоге мы прибили созданный с ошибкой сервис и это подобие кольца разорвалось.

Казалось бы, Kubernetes должен такие ситуации детектировать и запрещать создание ресурсов, которые будут ломать кластер. Но нет, проверяет он не всё. А потому прямо сейчас мы проводим большую работу, чтобы выявить все подобные слепые пятна K8s и наладить за ними контроль через admission-контроллер и OPA (Open Policy Agent).

Как подать заявку

  1. Написать текст для хаба Kubernetes. Если сомневаетесь, подойдёт ли тема — можно спросить у @mimizavr.

  1. При публикации добавить к посту тег «cезон Kubernetes». Важно: можно прикрепить тег и к старому посту, если он опубликован с 1 декабря 2022 г. по 24 февраля 2023 г.

  1. Дождаться проверки модератором. Если пост подойдёт под критерии сезона, мы отметим его специальной плашкой под заголовком и добавим в список под постом-анонсом. О результатах модерации отпишемся в личку.

И вот вы уже контейнеризованы и заоркестрированы.

Идеи для постов

Вот вам идеи от топового автора в хабе Kubernetes. Их можно взять в работу прямо так или использовать как отправную точку для своего творчества.

Дмитрий Шурупов aka Shurup

Open Source geek

  • Сравнение отечественных дистрибутивов Kubernetes: Deckhouse, Штурвал, NEOMSA.

  • Практические кейсы использования service mesh: какие задачи были решены, в чём профит для бизнеса.

  • WASM и Kubernetes: как это работает, есть ли тут будущее.

  • Kubernetes — он для Dev или Ops? Все обычно говорят только про Ops. Какие инструменты помогают сделать его всё-таки более удобным/юзабельным и для Dev?

  • Cloud-native-подход к CI/CD в Kubernetes (реализуем весь цикл доставки софта полностью в контейнерах).

Олег Зиновьев aka WellsBart

Автор

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

Ещё мне интересны инструкции для начинающих по развёртыванию K8s-кластера и т. п. темам.

Посты-участники

Не только работой едины — ARK+K3S+MetalLB.
Как-то играя в Ark, я захотел играть на своём сервере вместе с друзьями, и как раз под это дело у меня есть свой домашний сервер и выделенный IP, характеристик сервера более чем достаточно, в моём случае это Ryzen 7 1700X, 32Gb RAM и 1500Gb дисковой памяти. Как основу я взял контейнеризацию LXS и настроил внутри Ark сервер по первой инструкции, что нашёл в интернете, настроил service для Ark, чтобы руками его не запускать всё время.


Релизный цикл ПО для самых маленьких.
В продолжении нашей серии для начинающих айтишников о базовых идеях современной коммерческой разработки, поговорим о моделях релизов. Это очень обширная тема, но мы пройдёмся по верхам и исключительно с позиции разработчика. Мы не будем брать экзотические случаи, когда релизы относят на флешке, закрытой в специальном контейнере, или когда релиз ровно один — в конце разработки — и на нём всё заканчивается. Поговорим о популярном CI/CD, какую роль тут играет Kubernetes и почему фичи не сразу оказываются в проде.


Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1.
Многим в начале DevOps-пути доверяют только настройку CI/CD. Но потом в один прекрасный день тимлид приходит с задачей развернуть инфраструктуру для бэкенд-разработки, и возникает ступор. Я прошёл ровно этот путь: в процессе накопил много полезной информации, сформировал инструкцию и теперь делюсь ею с вами. Расскажу, с чего начать, что ставить и как ко всему подступиться.


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

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


Как создать cloud-init шаблон ОС Astra Linux в Proxmox
Сloud-init — это программа для инициализации виртуальных машин, обычно применяющаяся в облачных платформах. Но использовать cloud-init можно и локально, например в Proxmox, который успешно поддерживает данную технологию.

Всё, что нам надо — cloud-init-образ нужной ОС. Данная статья применима для любого cloud-init-образа. Я покажу, как это делать на примере Astra Linux 1.7.


ссылка на оригинал статьи https://habr.com/ru/article/708158/

Неизвестный Kickstarter: проекты в области робототехники и программирования, которые могли пройти мимо вас

Изучать крупнейшую площадку краудфандинга Kickstarter интересно, если ты сам занимаешься чем-то в области робототехники, микроэлектроники или программирования (как мы в RoboUniver). Хоть эта площадка уже несколько лет не так интересна для российских любителей краудфандинга (точнее недоступна для размещения, а сейчас еще вызывает проблемы с оплатой и доставкой), но посмотреть на интересные идеи, и на те вещи, которые, возможно, через несколько лет будут массовыми благодаря тем же «китайским друзьям» не будет бесполезным занятием.

Часть проектов «гремят» на весь мир, благодаря массированной медиа раскрутке, а часть собирают средства, выходят из стадии прототипов в реальное производство, но не получают должной известности. Мы решили исправить этот пробел и рассказать о проектах последних лет, которые привносят что-то новое и необычное в ИТ-обучение. Ссылки мы дадим на страницы проекта на KS, чтобы вы могли их также подробнее рассмотреть.

Arduino Based STEM Course/Curriculum and Learning Kit

Конструктор на основе Arduino в «чемоданчике». Авторы проекта вдохновлялись электронными конструкторами 70–80  годов прошлого века и предлагают создать с помощью данного конструктора множество интересных проектов: от простых датчиков света или движения, до таймеров обратного отсчета или цифровых будильников. По факту это учебный класс в одном чемодане, который идеально подойдет для образовательных учреждений, который позволит как быстро подготовиться к занятиям, так и быстро все сложить назад, не растеряв большую часть компонентов. Методические рекомендации и онлайн-курс обучения прилагаются.

Это не первый проект команды DUINOKit, у них на сайте вы сможете найти маленькие «чемоданчики» для опытов дома с детьми или большие, но на основе RaspberryPi 3.

Learn Python through Nursery Rhymes & Fairy Tales

«Изучайте Python с помощью детских песенок и сказок». Название проекта (и самой книги) немного обескураживает. И эта книга реально состоит из детских песенок и сказок, а также красивых полностраничных иллюстраций. Но все эти вещи написаны в виде программ на Python!

Например, вы читаете знакомую вам сказку про «Машу и трех медведей», затем вам предлагают ее интерпретацию по выбору кроваток на Python (причем эту программу вы можете запустить в любом интерпретаторе и получить результат в виде текста из сказки), а ниже рассказывают, что же вы при этом напечатали, какие команды языка использовали и как работает данный фрагмент кода.

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

Buildy Bots: Zero-screen time coding & robots for kids 5+

Берем конструктор с большими пластиковыми деталями, скрепляемыми большими пластиковыми болтами и гайками (если у вас были или есть маленькие дети, то вы видели или даже покупали такой). Добавляем к ним микроконтроллер, программируемый с помощью специальной кодовой панели, на которую устанавливаются фишки с пиктограммами команд. Оснащаем собранные модели двигателями, сенсорами и светодиодами и получаем Buildy Bots: робототехнический конструктор для детей от 5 лет (а нам кажется, что современные дети с ним справятся и в 4 года). Плюс авторы заявляют совместимость в LEGO (скорее всего с DUPLO).

По сравнению с массовыми «мышами» или «жуками», у данного конструктора есть преимущества, что ребенок может сам собрать разных роботов, технику или построить автоматизированный шлагбаум, а заодно и мелкую моторику разовьет. А в отличие от LEGO WeDo, здесь вам не потребуется планшет для написания программного кода.

Проект успешно собрал средства на Kickstarter и конструктор продается на мировых просторах. Отечественному производителю есть над чем призадуматься, особенно в свете новых веяний по обучению в детских садах.

Вот такие три проекта мы обнаружили на просторах Кикстартера, и это только часть из имеющихся. Новые проекты появляются регулярно, и если «тема зайдет», мы готовы рассказать и о других археологических STEM-находках. А если вы так же, как и мы интересуетесь робототехникой и программированием для детей, то приглашаем вас 8 января к нам на X Зимние РобоИгры на ВДНХ. Вход бесплатный, но нужно предварительно зарегистрироваться.


ссылка на оригинал статьи https://habr.com/ru/company/robouniver/blog/708512/

Подборка материалов для Android-разработчиков

Собрали список и про Kotlin, и про Java, и про алгоритмы, и про новые инструменты, и популярное чтиво есть. Почитать на новогодние выходные.

«Site Reliability Engineering: How Google Runs Production Systems», Бетси Бейер 

Это книга от Google, а значит она доступна бесплатно в онлайн-версии на английском. Почти 600 страниц (в печатной версии), 34 подробных главы…

…и 6 приложений с полезными материалами, вроде приложения с таблицами доступности…

…или с примерами постмортемов.

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

И пусть вас не смущает SRE в названии — книга будет полезна не только DevOps-инженерам, как это казалось бы на первый взгляд. 

Абакар Магомедов

Android Tech Lead в приложении Альфа-Мобайл

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

«Kotlin in Action», Дмитрий Жемеров, Светлана Исакова

Алексей Батурский

Android-разработчик в приложении Альфа-Мобайл

«Kotlin сейчас — стандарт де-факто в разработке мобильных приложений под Андроид, в книге довольно ёмко и лаконично описаны основные фичи языка»

Описано практически всё: от инструментария до документирования, от системы типов до конструирования DSL. Написано коротко, ясно, по существу…

…и с примерами.

«Совершенный код», Стив Макконел

Понять, что «Совершенный код» уже «взрослая» книга можно по обложке — сейчас таких не делают: ведь первое издание русскоязычной версии датируется 2005 годом, а англоязычную выпустили ещё в прошлом веке.

Но возраст здесь не помеха — принципы актуальны до сих пор, с учётом того, что есть довольно свежие версии с обновлениями.

Абакар Магомедов

Android Tech Lead в приложении Альфа-Мобайл

«Отличная книга о том, почему чистота кода это важно и как её поддерживать. В книге большое количество примеров, что делает её чтение ещё интереснее»

Но есть одно «Но». Автор очень любит писать — почти 900 страниц, как никак. Вот типичный абзац.

«На уровне архитектуры ПО сложность проблемы можно снизить, разделив систему на подсистемы. Несколько несложных фрагментов информации понять проще, чем один сложный. В разбиении сложной проблемы на простые фрагменты и заключается цель всех методик проектирования ПО. Чем более независимы подсистемы, тем безопаснее сосредоточиться на одном аспекте сложности в конкретный момент времени. Грамотно определенные объекты разделяют аспекты проблемы так, чтобы вы могли решать их по очереди. Пакеты обеспечивают такое же преимущество на более высоком уровне агрегации. Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции»

«Совершенный код», Стив Макконел

И, кажется, Стив понимает, что пишет очень много:)

Лаконичности предыдущей книги «Совершенному коду» не хватает:)

«Совершенный алгоритм. Основы», Тим Рафгарден

Абакар Магомедов

Android Tech Lead в приложении Альфа-Мобайл

«Очень интересная книга по алгоритмам. Автор описывает базовые термины как на научном, так и на простом языке. Причём даёт сразу две формулировки, чтобы сложилось более глубокое понимание предмета»

«Интересность» книги возникла не просто так. Ведь она основана на курсах по алгоритмам на Coursera, которые Рафгарден, в свою очередь, основал на лекциях, которые он же читал в Стэнфордском университете. Книга — это двойная производная от лекций, так сказать.

Шесть глав, 258 страниц, алгоритмы, и ничего лишнего.

«Effective Java, 3rd Edition», Joshua Bloch

— Так, а зачем здесь Java? Все новые приложения уже пишут на Kotlin!

Алексей Батурский

Android-разработчик в приложении Альфа-Мобайл

«Всё верно, но проекты с легаси, написанным на Java никто не отменял. А ещё сами исходники Android SDK на Java, а залезать в них во время работы придётся»

Как пишут в отзывах, вы «точно поймёте, как используется та или иная функция»

Раз уж речь зашла о Java, то следующая рекомендация…

«Java Concurrency in Practice», Brian Goetz

Алексей Батурский

Android-разработчик в приложении Альфа-Мобайл

«В современных мобильных приложениях довольно много асинхронной работы. Конечно, она уже закрыта за большим количеством абстракций (kotlin coroutines, rxjava2, HandlerThread) — но не лишним будет узнать, как всё это работает на более низком уровне. В книге приводится довольно много фундаментальных проблем связанных с многопоточностью и работой с памятью. Сложное, но интересное чтиво»

Многопоточность сложная вещь. Не то, чтобы правильно реализовать — трудно объяснить. Но здесь автор применяет хитрую уловку — показывает как не надо делать, прежде чем рассказать как надо.

«Jetpack Compose Internals», Jorge Castillo

Абакар Магомедов

Android Tech Lead в приложении Альфа-Мобайл

«Compose сейчас все больше набирает популярность, как инструмент построения UI на Android. В этой книге описано, как он устроен под капотом. Всегда полезно знать, как работает тот инструмент, которым пользуешься в повседневной разработке» 

Книга стоит 50 с лишним долларов и есть только на английском. Если это станет препятствием — можно почитать блог Хосе, там тоже достаточно статей о Jetpack Compose. Но глобального понимания, как книга, статьи не дадут.

«Идеальный программист»,  Роберт Мартин

Абакар Магомедов

Android Tech Lead в приложении Альфа-Мобайл

«Эта книга позволяет понять, что я не первый кто сталкивается с определенным типом проблем в карьере программиста и успокаивает даже снимает синдром самозванца. Если уж такой человек как Роберт Мартин ошибался и спокойно может написать книгу о своих ошибок, то и в моем случае в этом нет ничего критичного. Главное учиться на каждой своей ошибке»

В целом, книга скорее мотивирующая, чем техническая — в формате жизненный историй и уроков.

Прочитав её, сразу становится понятно, какую мораль (в хорошем смысле)  от Роберта мы прочтём. Книгу можно читать даже если вы далеки от разработки — советы универсальные (почти все).

«Extreme Programming», Kent Bek

Никита Горбунов

Ведущий Android-разработчик в приложении Альфа-Мобайл

Книгу можно назвать гайдом по созданию ПО. Писал её человек с большим опытом, который успел поучаствовать в большом количестве проектов. Так лучше чем наступать на свои грабли прочитать о чужих»

«С большим опытом» это даже скромно:) Кент Бек — это легенда: один из авторов шаблонов/паттернов проектирования (да, у идеи паттернов есть авторы), автор JUnit, автор книг и подхода экстремального программирования. Это не все достижения, для этого есть отдельная статья у JUG Ru. Но даже этого короткого списка хватит, чтобы записать книгу в список обязательных для чтения.

На этом всё — оставайтесь на связи.


Рекомендуем почитать [подборка редактора блога]:

Подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, и другие подборки, иногда шутим.


ссылка на оригинал статьи https://habr.com/ru/company/alfa/blog/708518/