Научный подход к исследованию способа полёта Карлсона

Карлсон знаком нам всем с детства, а вы когда-нибудь задумывались, как он был устроен?
Из чего был сделан пропеллер на его спине? Откуда взялся человек, обладающий недоступной для всех нас возможностью парить в воздухе? Как винт крепился к человеческому телу и вращался в нём? Почему весёлый человек был такого маленького роста?
Кем же он был: человек, робот или, может быть, кибернетический организм с электронным мозгом?

Проще всего его необычность списать на фантазию ребенка или писательницы Астрид Линдгрен, но не будем с этим спешить. Есть и доводы в пользу его реального существования.
Как, вы думаете, на самом деле был устроен странный незнакомец, так ловко жонглирующий законами физики? Давайте сегодня, 1 Апреля 2021 года, вместе найдем ответ на этот животрепещущий вопрос.

image

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

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

И самый первый вопрос, который задаст себе дотошный читатель книги: «Если у Карлсона один винт, то почему его тело в полете не вращается в противоположную сторону?»

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

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

В Сети по поводу отсутствия вращения приводятся довольно убедительные версии. Рассмотрим их по одной.
1. Внутри Карлсона находится гироскоп, который своим вращением стабилизирует полет.
Но ведь речь идет о полёте. Гироскоп для этой цели получился бы слишком тяжелым. Эта версия не подходит.

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

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

Пропеллер для полёта

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

Как указывала сама писательница в сборнике автобиографических очерков «Мои выдумки» (Mina påhitt, 1971), она росла в век «лошади и кабриолета». Основным средством передвижения для семьи был конный экипаж, темп жизни был медленнее, развлечения — проще, а отношения с окружающей природой куда более тесными, чем сегодня.

— https://ru.wikipedia.org/wiki/Карлсон

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

image

В меру упитанный, в самом расцвете сил

Обратим внимание, что выход книги свершился в 1955 году. Не так давно отгремела Вторая Мировой война, а в период войны разработки новых вооружений и способов повышения боеспособности личного состава развивались как никогда. Вспомним »усилители выносливости», применявшиеся армиями Германии, японские исследования пределов человеческого организма, довоенные эксперименты Воронова по пересадке эндокринных органов, советские эксперименты по выведению сверхчеловека и послевоенные опыты Демихова по пересадке голов собакам.

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

image

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

Летать и не падать

Но как мог пропеллер крепиться к человеческой плоти? С одной стороны, в книге утверждается, что он приводился в действие кнопкой, которая запускала мотор. Возможность размещения металлического мотора в живом организме кажется ничтожной, ведь у такого мотора должен быть неимоверно маленький вес и просто невероятный КПД!

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

Именно в Швеции был запатентован первый корабельный винт. Шведы первыми принесли в мир динамит, УЗИ и первую телефонную трубку. Невероятные для своего времени изобретения шведов и, в особенности, корабельный винт, наталкивают на мысль, что именно в Швеции могли изобрести нечто подобное.

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

Современные авиамодели тоже могут летать вверх ногами, и это также становится возможным при использовании автомата перекоса.

image

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

Для стабилизации полёта в авиамоделях, действительно, применяется гироскоп — но это уже не механическое, а электронное устройство, и во время войны таких ещё не было изобретено. И тут опять приходится задействовать природные органы: в роли гироскопа, стабилизирующего полёт, у Карлсона просто-напросто выступал его вестибулярный аппарат.

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

Можно допустить, что в организме Карлсона лопасти крепились по отдельности, как у стрекозы, и каждая управлялась отдельными мышцами. И предположить, что автомат перекоса был выполнен еще проще, когда мышцами изменялся угол наклона всего "двигателя" вместе с пропеллерами и ротором.

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

В банке не осталась хотя бы капелька варенья?

Помните, как Карлсон убеждал Малыша в необходимости особенной пищи, которая ему подходит: сладостей и варенья? Это была не прихоть, а жизненная необходимость: ему нужня высококалорийная пища, богатая "быстрыми" углеводами. Такая еда быстрее всего перерабатывается в энергию и работает в качестве "топлива".

image

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

Мы помним про существование кнопки пуска мотора на животе у Карлсона, которую он нажимал, желая полететь.

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

Мозг и система управления

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

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

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

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

Возможно, что кому-то из шведских хирургов удалось срастить импланты из легковесных искусственных материалов с костной системой человека без отторжения. Несомненно, хирург за такие заслуги получил бы Нобелевскую премию, если бы не секретность его работ. Альфред Нобель тоже был шведом, и это был как раз тот человек, который изобрел динамит. У вас еще остались сомнения в возможности причастности Швеции к подобным разработкам?

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

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

Что происходило дальше? Прототип нового солдата в поисках пропитания увидел ребенка, попавшего в беду. Что он подумал? Возможно, он увидел в детских глазах такое же ощущение одиночества и непонятости, какое-то отражение себя, и решил помочь, при этом, не раскрывая себя. И вернул ребёнку тягу к жизни.

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

А может, он всегда был таким весёлым, потому что уже и не надеялся обрести вторую жизнь, которую, через тяжёлые испытания, он обрёл вместе с новым телом — настоящим шедевром шведской науки!

Материалы, использованные в данном исследовании:
https://habr.com/ru/post/399053/
https://pikabu.ru/story/skhema_razbora_karlsona_1598037
https://politikus.ru/articles/politics/56971-malysh-i-karlson-nauchnyy-perevod.html
https://ru.wikipedia.org/wiki/Карлсон
https://commons.wikimedia.org/wiki/File:Russian_Air_Force_Kamov_Ka-50.jpg?uselang=ru
https://russian.rt.com/article/10051
https://kulturologia.ru/blogs/200716/30533/
https://novate.ru/blogs/141116/38812/
https://fjord.su/article/samye-izvestnye-izobreteniya-iz-shvecii.html
https://pikabu.ru/story/vladimir_petrovich_demikhov__geniy_transplantologii_7521547

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

FrontEnd разработка в Docker

Легенда

Когда приходит новый разработчик, то перед ним встает задача запустить окружение для разработки. И до недавнего времени — это часто становилось похожим на танцы с бубном. Поставь 10 разных пакетов определенных версий, а еще окажется что твой собственный pet-проект требует другие версии или это даже может быть другой проект в рамках той же работы. Каждый раз из этой ситуации специалист выходил по своему, но основной проблемой помимо временных затрат на эту конфигурацию — оставалось, то что работоспособность от разработчика к разработчику или runner не гарантировалась.

К счастью — эта проблема решена в современном мире разработки, если не полностью, то в большей мере. Нам на выручку пришел Docker.

Данная статья сделана для FrontEnd разработчиков, которые не знакомы с Docker. Мы разберем некоторые вопросы связанные с оптимизацией трафика для запуска и затронем немного вопросы безопасности.

По итогу, мы:

  1. Научимся работать с Docker для локальной разработки

  2. Создадим артефакт для production, который в будущем сможет использовать DevOps.

  3. В конце немного поговорим о безопасности

Установка Docker

Установка докер довольна простая и лучше всего описана в официальной документации: https://docs.docker.com/get-docker/

Также нам для работы понадобится docker-compose, например для MacOS при установке Docker Desktop он также автоматом установится, в linux системах же его придется ставить отдельно: https://docs.docker.com/compose/install/

Справка по CLI Docker

docker и docker-compose поддерживают флаг —help для корня и для команд

docker --help docker ps --help docker-compose --help docker-compose up --help

Особенности проекта в статье

Пусть наш FE проект имеет 2 скрипта в package.json: «dev» для разработки и «build» для создания production кода.

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

GitHub: тут

TL;DR; Сразу код

docker-compose.dev.yml
version: "3.9" services:   web:     image: node:15.8-alpine3.11     ports:       - "3000:3000"     volumes:       - ".:/app"     environment:       NODE_ENV: development       HOST: 0.0.0.0     working_dir: /app     command: sh -c "cd /app; yarn install; yarn run dev --host 0.0.0.0"
docker-compose.yml
version: "3.9" services:   web:     build:       context: .       dockerfile: Dockerfile     ports:       - "80:80"     environment:       NODE_ENV: production 
Dockerfile
FROM node:15.8-alpine3.11 AS build WORKDIR /app COPY package.json package.json RUN yarn install COPY . . RUN yarn build  FROM nginx:1.19-alpine COPY --from=build /app/dist /opt/site COPY nginx.conf /etc/nginx/nginx.conf 
nginx.conf
worker_processes auto;  events {     worker_connections 8000;     multi_accept on; }  http {   include       /etc/nginx/mime.types;   default_type  application/octet-stream;    server {       listen   80;       listen   [::]:80 default ipv6only=on;        root /opt/site;        location / {           try_files $uri $uri/ /index.html;       }   } } 

Давайте разбираться, что произошло:

Этап разработки:

docker-compose.dev.yml — Этого фала достаточно для разработки, остальные файлы используются для создания production артефакта

1 шаг. Объявляем сервис ‘web’. Выбираем образ который будет делать сборку: node:15.8-alpine3.11 Лучше всего детализировать используемые версии, стоит их держать точно такими же, как и у сборщика production build.

2 шаг. Выбираем порты, которые будут в нашей хост системе отражать порты из запущенного контейнера.

3 шаг. Монтируем все из текущей директории в контейнер. Это нужно, чтобы локальные изменения сразу вызывали rebuild, однако это порождает некоторые проблемы с безопасностью — разберем их в конце статьи.

4 шаг. ‘environment’ позволяет задать переменные окружения, которые интересны в твоем конкретном случае.

5 шаг. ‘working_dir’ определяет рабочую директорию внутри контейнера, относительно которой будут исполнены последующие команды.

6 шаг. Устанавливаем зависимости и стартуем разработку (webpack-dev-server с явным заданием хоста): command: sh -c "yarn install; yarn run dev --host 0.0.0.0”

Запускаем разработку с помощью команды: docker-compose -f docker-compose.dev.yml up

Этап production:

Хочу особо отметить, что приведенная конфигурация работает для отдачи простой статики. Если используется SSR, нужно будет внести изменения: поднимать сервер на node и т.д.

Что отличается в конфигурации docker-compose.ymlот develop версии?

  1. Указана сборка из Dockerfile, вместо использования образа image

  2. Поменялась переменная окружения NODE_ENV: development-> production

  3. Нет секции command потому что статика будет раздаваться с помощью nginx

Конфигурация nginx максимально простая и не обременяет процесс раздачи файлов и fallback на /index.html в случае, если пытаются получить какой-то файл, которого нет.

Самое интересное кроется в Dockerfile: multi-stage building, который используется для уменьшения результирующего артефакта.

Dockerfile

Первая стадия — это сборка

1 строка. Для этого указываем тот же исходный образ, который использовали для develop FROM node:15.8-alpine3.11 AS build

Важно! Даем стадии имя build, чтобы в следующих стадиях именовать ее по имени, а не по индексу, который может измениться, если включим дополнительные стадии.

2 строка. Указываем рабочую директорию /app

3-5 строки. Здесь останавливаемся подробнее:

Вопрос: почему сначала копируем только package.json и производим установку?
Ответ (не заставляет себя долго ждать): при первом запуске разница не будет заметна, но уже со следующей попытки сборки разница будет очевидна.

Если не было изменений в “package.json”, то слои, по которым собирается docker не изменятся, и данные шаги будут просто взяты из кэша. Это многократно ускорит процесс и снизит сетевую нагрузку в разы. Нам как раз это и надо.

6 строка. Копируем оставшиеся файлы и запускаем build.

Вторая стадия — формирование артефакта

По своей сути артефакт в нашем случае — это контейнер nginx со статикой.

8 строка. Указываем образ nginx который возьмем за основу.

9 строка. Копируем файлы из первой стадии в папку из которой будем раздавать статику.

10 строка. Копируем в артефакт файл конфигурации nginx

Запускать артефакт можно например так: docker-compose up

Немного о проблеме безопасности для deveopment

Не стоит использовать volumes с директориями на компьютере, которые не хотим отдать в доступ всем пользователям docker.

Как это проявляется? Давайте рассмотрим на примере:

Создаем обычную папку ~/project. Добавляем в нее файл secret.txt, который содержит текст: “secret text”

Под пользователем создаем docker-compose.ymlи подключаем директорию, к которой не имеет доступ другой пользователь.

docker-compose.yml
version: "3.9" services:   web:     image: alpine:latest     volumes:       - "./project:/app"     command: sh -c "sleep 3600”

Строка 7. Контейнер будет жить 1 час.

Запускаем: docker-compose up -d

Заходим в систему под другим пользователем, который имеет доступ к docker.

Смотрим имя контейнера: docker ps

Заходим в контейнер: docker-compose exec -it {имя_контейнера} /bin/sh

Теперь можно спокойно зайти в папку: cd /app 

В которой лежит секретный файл sectret.txt
Файл можно просматривать и редактировать его содержимое.

Итоги

Несомненно, тема контейнеризация очень обширная и мы рассмотрели только крошечную часть, однако мы рассмотрели необходимую базу для старта. Я буду рад, если эта статья станет отправной точкой для FE-разработки в Docker.

GitHub: тут

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

Валидные сертификаты и DNS для сервисов в локальных сетях без удостоверяющего центра

Валидные сертификаты и DNS для сервисов в локальных сетях без удостоверяющего центра

В этом посте будет рассмотрена установка и использование сервиса http://local-ip.co/ с валидными сертификатами и с DNS как xip.io, nip.io.

Вы можете использовать сертификат для домена *.my.local-ip.co

Обращаться нужно будет примерно так:

Ниже будет пример с установкой harbor c валидным сертификатом.

Требования:

Устанавливаем docker и docker-compose

Скачиваем harbor

wget https://github.com/goharbor/harbor/releases/download/v2.2.1/harbor-online-installer-v2.2.1.tgz

Распаковываем harbor

tar xvf harbor-online-installer-v2.2.1.tgz

Подготавливаем сертификаты от проекта http://local-ip.co/

mkdir -p /data/cert/ cd /data/cert/ wget http://local-ip.co/cert/server.pem wget http://local-ip.co/cert/chain.pem wget http://local-ip.co/cert/server.key

Создаем цепочку сертификатов

cat server.pem chain.pem > bundled_cert_file.pem

Переименовываем сертификаты под доменное имя, которое вам нужно будет.

cp bundled_cert_file.pem 192-168-22-7.my.local-ip.co.crt cp server.key 192-168-22-7.my.local-ip.co.key

Копируем шаблон конфига в конфиг

cp harbor.yml.tmpl harbor.yml

Конфигурируем hostname в harbor.yml

hostname: 192-168-22-7.my.local-ip.co

Указываем сертификат и ключ в harbor.yml

  certificate: /data/cert/192-168-22-7.my.local-ip.co.crt   private_key: /data/cert/192-168-22-7.my.local-ip.co.key

Запускаем скачивание образов

./prepare

Запускаем harbor через docker-compose

docker-compose up -d

Либо запускаем установку

./install.sh

Установка harbor через Ansible

Для установки harbor через ansible используем роль https://galaxy.ansible.com/manueliglesiasgarcia/ansible_vmware_harbor

Скачиваем роль

ansible-galaxy install manueliglesiasgarcia.ansible_vmware_harbor

Ниже playbook для установки harbor через ansible

--- - name: Install harbor   become: yes   hosts: harbor   pre_tasks:     - name: update apt       apt: update_cache=yes cache_valid_time=3600       when: ansible_pkg_mgr is defined and ansible_pkg_mgr == "apt"       ignore_errors: true      - name: Creates directory {{ playbook_dir }}/certs       file:         path: "{{ playbook_dir }}/certs"         state: directory       delegate_to: localhost       become: no      - name: Download http://local-ip.co/cert/server.pem       get_url:         url: http://local-ip.co/cert/server.pem         dest: "{{ playbook_dir }}/certs/server.pem"       delegate_to: localhost       become: no      - name: Download http://local-ip.co/cert/chain.pem       get_url:         url: http://local-ip.co/cert/chain.pem         dest: "{{ playbook_dir }}/certs/chain.pem"       delegate_to: localhost       become: no      - name: Download http://local-ip.co/cert/server.key       get_url:         url: http://local-ip.co/cert/server.key         dest: "{{ playbook_dir }}/certs/server.key"       delegate_to: localhost       become: no      - name: merge certificate       shell: cat server.pem chain.pem > bundled_cert_file.pem       args:         chdir: "{{ playbook_dir }}/certs"       delegate_to: localhost       become: no    vars:     # Add a registry     harbor_registry:       - registry_name: "Test Harbor"         registry_url: https://192-168-22-8.my.local-ip.co/     # Schedule an automatic scan of the docker images every hour     harbor_schedule_scan:       - cron: "0 0 * * * *"     # Schedule an automatic garbage collection every hour     harbor_schedule_gc:       - cron: "0 0 * * * *"     #Storge harbor installation file     harbor_install_tmp: /root/harbor     harbor_extras:       -  clair     #Folder installed harbor     harbor_install_dir: /opt/harbor     # The cert and key path is located in your ansible master, not the target hosts     # The default path for certs is controlled by this role See roles/default/main.yml     harbor_ssl_cert: "{{playbook_dir}}/certs/bundled_cert_file.pem"     harbor_ssl_cert_key: "{{playbook_dir}}/certs/server.key"     #ends up in harbor.yml     harbor_hostname: 192-168-22-8.my.local-ip.co     harbor_db_password: admin   roles:     - manueliglesiasgarcia.ansible_vmware_harbor 

Запускаем playbook

ansible-playbook -i inventory.ini install-harbor.yml -e "harbor_admin_password=password_for_harbor"

Где password_for_harbor пароль для harbor.

Скриншот:

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

Опыт разработки виджетов для сторонних сайтов

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

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

Библиотека

Не нужно думать, что виджет у вас будет один.

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

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

Поэтому сразу проектируем код таким образом, чтобы он позволял вставлять неограниченное число разных виджетов на одну страницу без ограничений. Первое, что приходит в голову: «а давайте просто выведем iframe с нашего сайта?». И сделаем код вида:

<iframe src="https://company.name/my-widget" frameborder="0" scrolling="no" width="300" height="200">        Ваш браузер не поддерживает фреймы! </iframe>

И это будет большой ошибкой по нескольким причинам.

Невозможность расширения

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

Может, для начала это не критично, но по мере развития в это легко можно упереться, а код на сайтах уже установлен.

Про то, какие проблемы есть в работе с iframe и их решении, поговорим попозже.

Лишние запросы на бэкенд

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

А как надо делать?

Если вы когда-нибудь устанавливали на сайт какой-нибудь виджет, например, от ВК, то могли заметить, что код виджета разделен на две части: библиотеку (SDK) и инициализацию виджетов:

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

Мы видим, что для вставки любого виджета нужно один раз подключить SDK и добавить один пустой тэг с инициализацией виджета. А дальше все делает javascript: он может делать любые запросы и любое их количество на бэкенд, и разработчики виджета могут в любой момент эту логику изменить без изменения кода виджета на сайте. В итоге из html на сайте для виджета должен быть только пустой контейнер с уникальным id. Чтобы не томить вас ожиданием, давайте сразу напишем пример SDK и рендер простого виджета. 

А потом поговорим о том, что же у нас получилось и на что стоит обратить внимание.

Код библиотеки
namespace MyCompany {     /**      * Виджет кнопки      */     class Button {         /**          * Внутренний id кнопки          */         protected id: number;          /**          * DOM элемент контейнера          */         protected containerElement: HTMLElement;          /**          * Инстанс api          */         protected apiInstance: Api;          /**          * Constructor          * @param {Api} instance          * @param {string} containerId          */         public constructor(instance: Api, containerId: string) {             this.apiInstance = instance;             this.containerElement = document.getElementById(containerId);         }          /**          * Инициализация          */         public init(): void {             this.containerElement.innerHTML = '<button>Виджет кнопки</button>';         }     }      /**      * Основной класс Api      */     export class Api {          /**          * Виджет кнопки          * @param {string} containerId          * @return {MyCompany.Button}          */         public button(containerId: string): Button {             const widget = new Button(this, containerId);             widget.init();             return widget;         }          /**          * Запуск колбеков инициализации          */         public runInitCallbacks(): void         {             let myCompanyApiInitCallbacks = (window as any).myCompanyApiInitCallbacks;             if (myCompanyApiInitCallbacks && myCompanyApiInitCallbacks.length) {                 setTimeout(function () {                     let callback;                     while (callback = myCompanyApiInitCallbacks.shift()) {                         try {                             callback();                         } catch (e) {                             console.error(e);                         }                     }                 }, 0);             }         }     } }  /**  * Инициализация Api  */ if (typeof (window as any)['myCompanyApi'] === 'undefined') {     (window as any).myCompanyApi = new MyCompany.Api();     (window as any).myCompanyApi.runInitCallbacks(); }
Код вставки
<!-- в head один раз --> <script async type="text/javascript" src="https://mycompany.site/js/api/api.min.js"></script>  <!-- в место вызова виджета --> <div id="button-container-5ef9b197c865f"></div> <script type="text/javascript">     (function() {         var init = function() {             myCompanyApi.button('button-container-5ef9b197c865f');         };         if (typeof myCompanyApi !== 'undefined') {             init();         } else {             (myCompanyApiInitCallbacks = window.myCompanyApiInitCallbacks || []).push(init);         }     })(); </script>

Выглядит страшно и как-то избыточно, давайте разбираться, зачем все это.

Асинхронность

Сразу в глаза бросается атрибут async у тэга script. Он позволит браузеру не ждать загрузки нашего скрипта и продолжить отрисовывать сайт. Это важно: если по каким-то причинам наш скрипт будет недоступен (недоступен сервер, фаервол компании), это не должно влиять на скорость загрузки сайта клиента. Но все не так просто. Раз скрипт загружается асинхронно, это значит, что когда браузер дойдет до места, где инициализируется наш виджет, наш SDK может быть еще не загружен, и если просто вызвать метод из библиотеки — будет ошибка, причем плавающая, в зависимости от того, успел загрузиться скрипт или нет.

Поэтому в месте вызова виджета мы должны обработать оба сценария, когда SDK загрузилось и еще нет.

В первом случае мы просто вызываем функцию init(). Во втором — откладываем выполнение этой функции до момента, когда скрипт загрузится, добавляя замыкание в очередь. А последней строчкой в нашем SDK вызывается метод runInitCallbacks, который как раз и выполнит все отложенные инициализации.

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

Теперь наш код запускается всегда и не блокирует отрисовку страницы!

Изоляция

Название объекта SDK и id контейнеров должны быть уникальными, ведь наш код будет выполняться на совершенно разных сайтах. Ни в коем случае нельзя нарваться на совпадения. ID контейнеров желательно генерировать уникальными, например, через uniqid(). Нельзя надеяться и на сторонние библиотеки, установленные на сайте, и совсем не желательно приносить их с собой. Да, я о jQuery, как вы уже догадались.

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

На кодировку сайта тоже не стоит полагаться, и даже в наше время встречаются сайты на cp1251. Поэтому кодировку скрипта нужно явно задать в ответе сервера в заголовке Content-Type.

Код, написанный нами выше, позволяет не останавливаться на одном виджете: сейчас у нас есть только myCompanyApi.button(), но ничего не мешает добавить другие виджеты.

Кеширование

Мы будем постоянно дорабатывать наш SDK, но браузеры кэшируют скрипты, если разработчик не дал других инструкций. Мы должны сами задать время, на которое можно кешировать нашу библиотеку, через заголовок Expires, например, час — адекватное время. С кешированием на фронтенде разобрались, теперь поговорим про бэкенд. Как уже обсуждали выше, обслуживание запросов со сторонних виджетов может создавать ощутимую нагрузку просто от количества сайтов, где виджеты установлены. Но чаще всего данные для всех пользователей в этих виджетах одинаковые, нет смысла запускать приложение, а тем более ходить в базу данных за ними на каждый запрос. Такие запросы вообще дальше nginx можно не пропускать, настроив кеширование на нем. 

Если для отрисовки виджета нужны данные с бэкенда, но в целом можно отрисовать минимальную версию и без него (например, кнопку покупки билетов, но без признака наличия), хорошим тоном будет сделать fallback: если данные не загрузились за полсекунды, рисовать обрезанную версию виджета, а как только данные получены — дорисовывать. Это визуально ускорит загрузку и покажет виджет даже без работающего бэкенда (вдруг он при взаимодействии уже поднимется?).

Немного про iframe

Iframe — по сути, отображение сайта в сайте. Вернемся к нашему кейсу с кнопкой покупки билетов. Если мы хотим при клике открывать попап со страницей выбора места — без iframe нам не обойтись. Какие же там есть нюансы?

Неработающие cookie

Уже давно многие браузеры по умолчанию начинают запрещать использование cookie для сторонних сайтов (это когда домен iframe отличается от родительского сайта). Это значит, что при переходе между страницами внутри фрейма не получится отследить сессию (localStorage тоже не работает).Тут выход простой — не перезагружать страницы и делать SPA. Идентификатор сессии можно будет легко сохранить в переменной в js.

Общение с  SDK

Часто требуется организовать общение нашего SDK с приложением внутри iframe, например, мы хотим при открытии виджета растянуть размер фрейма под размер контента. Для этого нам нужно сообщить размер контента из iframe в родительское окно. Это можно легко сделать через postMessage. Будьте внимательны при передаче конфиденциальных данных и верно указывайте targetOrigin, иначе данные могут «подслушать» другие сайты.

Спасибо за внимание, надеюсь, вы узнали для себя что-то новое.

Сергей Никитченко, Студия Валерия Комягина

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

На каких серверах держится Архив Интернета?


Фото 1. Один из дата-центров Internet Archive в Сан-Франциско

Internet Archive — некоммерческая организация, которая с 1996 года сохраняет копии веб-страниц, графические материалы, видео- и аудиозаписи и программное обеспечение. Каждый может зайти в Wayback Machine и посмотреть, как выглядел Хабр в 2006 году или «Яндекс» в 1998 году, хотя загрузка архивных копий занимает около минуты (это не для реализма 90-х, а по техническим причинам, см. ниже).

Архив быстро растёт. Сейчас объём всех накопителей достиг 200 петабайт. Но Internet Archive принципиально не обращается к стороннему хостингу или облачному сервису вроде AWS. У некоммерческой организации собственные дата-центры, свои серверы и свои инженеры. Это гораздо дешевле, чем услуги AWS.

Архив Интернета против облаков

Технические подробности серверного устройства Internet Archive раскрыл Джона Эдвардс (Jonah Edwards), руководитель инженерной группы Core Infrastructure Team.

По его мнению, понятие «облако» многих людей вводит в заблуждение как нечто абстрактное. На самом деле это просто чужие компьютеры, то есть серверы посторонней компании. Для Internet Archive это неприемлемо. У организации собственные серверные в собственных зданиях, компьютеры принадлежат им, и персонал тоже свой.


Четыре дата-центра Internet Archive располагаются в Сан-Франциско, Ричмонде и Редвуд-Сити (это пригороды Сан-Франциско)

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

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

Инфраструктура

Что представляет собой инфраструктура, которой управляет Core Infrastructure Team? На февраль 2021 года цифры такие:

  • 750 серверов, возраст до 9 лет;
  • 1300 виртуальных машин;
  • 30 000 устройств хранения данных;
  • более 20 000 жёстких дисков в парах друг с другом (paired storage), обычно пара разнесена по дата-центрам или странам для надёжности;
  • общий объём накопителей почти 200 петабайт.

Разумеется, техника постепенно обновляется. На смену старым накопителям приходят новые. Например, маленькие диски на 2 и 3 терабайта полностью вышли из обращения в 2017 и 2018 годах, соответственно, а с прошлого года постоянно растёт доля дисков на 16 ТБ.

Как показано на графике ниже, несмотря на увеличение ёмкости накопителей, общее число HDD тоже постепенно растёт: за три года оно выросло с 15 тыс. до 20 тыс.


Количество жёстких дисков разного объёма на серверах Internet Archive

Диски реплицируются по дата-центрам, для производительности контент по запросу выдаётся одновременно со всех копий. Все элементы Архива представляют собой директории на дисках. Веб-страницы Wayback Machine хранятся в файлах WARC (Web ARChive, сжатые файлы Web Archive). При запросе отдельной страницы её нужно извлечь из середины архива WARC, а если страница требует загрузки дополнительных ресурсов, то процесс повторяется. Это одна из причин, почему полная загрузка страниц из Wayback Machine достигает 90 секунд, хотя закэшированные копии и популярный контент загружаются быстрее.

Для надёжности копии Архива хранятся не только в Сан-Франциско, но и ещё в нескольких локациях по всему миру, в том числе в Амстердаме (Нидерланды) и Новой Александрийской библиотеке (Египет).

В 1996 году первые серверы Internet Archive подняли на недорогих компьютерах из стандартных комплектующих: по сути, на обычных десктопах под Linux. Хотя инфраструктура сильно выросла, в качестве операционной системы всегда использовали только Linux. С 2004 года все серверы перешли на Ubuntu, сейчас продолжается миграция на Ubuntu 20.4 LTS (Focal Fossa).

Объём Архива

В последнее время объём Архива возрастает примерно на 25% в год, сейчас это соответствует 5−6 петабайтам в квартал. С учётом резервных копий нужно добавлять накопителей на 10−12 петабайт в квартал.

Одна копия Архива занимает более 45 петабайт, но на дисках и лентах хранится минимум две копии каждого объекта.

Как видно на графике вверху, обновление дискового массива происходит только за счёт моделей максимальной ёмкости. Например, в конце 2021 года планируется переход на диски по 20 ТБ, и тогда в серверы будут устанавливать только их. Остальные HDD постепенно доживают свой век, и их количество медленно снижается.

Internet Archive возлагает большие надежды на новые технологии записи данных, такие как HAMR (heat-assisted magnetic recording), чтобы ёмкость HDD увеличивалась ещё быстрее. Технология HAMR предусматривает предварительное нагревание магнитной поверхности лазером в процессе записи, что позволяет значительно уменьшить размеры магнитной области, хранящей один бит информации — и увеличить плотность записи. Нагрев выполняется с помощью лазера, который за 1 пс разогревает область записи до 100 °C.

Разработка этой технологии затянулась на 15 лет, но в январе 2021 года были официально представлены первые диски HAMR на 20 ТБ. Пока что они официально поставляются только избранным клиентам в рамках фирменного сервиса Seagate Lyve, но вскоре должны появиться в свободной продаже.

Seagate обещает, что HAMR позволит наращивать ёмкость HDD на 20% в год. Поэтому в ближайшее время можно ожидать модель на 24 ТБ, а в будущем — диски на 30 и 50 ТБ. Internet Archive тоже надеется на это и внимательно следит за последними разработками.

На текущем размере дисков понадобится 15 вот таких серверных стоек, чтобы разместить одну копию Архива:


У Internet Archive 750 серверов и 20 000 жёстких дисков

Сейчас в дата-центрах установлено 75 серверных стоек, что обеспечивает некоторый запас и избыточное копирование.

По состоянию на февраль 2021 года на серверах хранились копии 534 млрд веб-страниц, 16 млн аудиозаписей, 8,7 млн видеозаписей фильмов, клипов и телепередач, 3,8 млн изображений, 629 тыс. компьютерных программ, более 29 млн книг и текстов, в том числе 72 771 текст на русском языке.

Любой пользователь может создать аккаунт и добавить в архив медиафайлы.

Internet Archive поддерживает API для внешних сервисов. Например, сторонний сервис может забирать контент из хранилища и показывать его на своём сайте или в приложении. Можно строить собственные каталоги на базе этого хранилища, эксплуатируя IA просто как удалённый бесплатный хостинг файлов с хотлинками. Подобную модель использует книжный каталог Open Library на базе Internet Archive. Хотлинки и модель подобной «эксплуатации» собственных ресурсов поощряется со стороны Архива. Кстати, аналогичные правила действуют в Wikimedia Commons: хотлинкинг разрешён и даже поощряется, что недавно вызвало казус с фотографией цветка: по непонятной причине ежедневно в сеть Wikimedia Commons поступало около 90 млн одинаковых запросов на получение одного файла AsterNovi-belgii-flower-1mb.jpg. Будем надеяться, что у Internet Archive таких инцидентов не случится.

Сеть

В 2020 году Internet Archive пережил серьёзный рост количества запросов и объёма внешнего трафика с 40 до 60 Гбит/с. Из-за пандемии коронавируса и самоизоляции ресурсы Архива стали более востребованы. Количество запросов росло так быстро, что в определённый момент маршрутизаторы Internet Archive перестали справляться с нагрузкой, пришлось делать апгрейд сетевой инфраструктуры быстрее, чем планировалось. Сейчас веб-сайт входит в топ-300 крупнейших сайтов интернета.

Работа на собственных серверах имеет и свои недостатки. Основные причины сбоев Internet Archive — обрывы оптоволокна из-за строительных работ в городе, сбои энергоснабжения, случайные провалы напряжения в сети. Впрочем, прошлый год сайт завершил с аптаймом 99,9%.

Internet Archive планирует расширять внешний канал. Ожидается, что в ближайшее время внешний трафик вырастет до 80 Гбит/с.

Примерно так выглядит дизайн внутренней сети:

Дата-центры подключены к нескольким провайдерам первого уровня (Tier 1) и соединены между собой по оптоволокну с применением технологии плотного спектрального уплотнения (DWDM). Локальные университетские сети подключаются к этому кольцу напрямую через локальные точки обмена трафиком.

Вместо нынешнего оптоволокна планируется проложить пары 100-гигабитных кабелей по всему кольцу из четырёх дата-центров, так что внешний трафик тоже можно будет увеличить до 100 Гбит/с.

Прокладка новых кабелей по Сан-Франциско — весьма хлопотное и дорогое дело. Приходится перекладывать асфальт на автомобильных дорогах и тротуарах. К счастью, Internet Archive удалось получить официальный статус библиотеки, что даёт доступ к государственным субсидиям, в том числе к бюджету Федеральной комиссии по связи США (FCC) на подключение всех библиотек к интернету. Таким образом, львиную долю расходов на прокладку, обслуживание оптоволокна и трафик оплачивает FCC по программе E-Rate Universal Service Program.

С 2005 года Internet Archive начал проект Open Library по сканированию книг. С одной стороны, это действительно важный общественный проект. С другой стороны, он позволил получить государственные льготы и финансирование в качестве публичной библиотеки.

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

Планы на будущее

Инженеры Internet Archive сейчас обдумывают варианты использования SSD и GPU в основных серверах, чтобы увеличить их производительность. Главная проблема здесь в том, что все дата-центры находятся в стеснённых городских условиях Сан-Франциско и пригородов с очень ограниченными возможностями охлаждения (см. фото 1). Так что каждый апгрейд требуется хорошо обдумать: не приведёт ли он к повышению температуры.

Интересно наблюдать за ростом инфраструктуры Internet Archive с увеличением количества серверных стоек. Есть подозрение, что рано или поздно наступит момент, когда сложность поддержания своей инфраструктуры превысит некий порог — и библиотека откажется от собственных дата-центров. Но пока что инженеры Core Infrastructure Team успешно справляются с работой.

В зависимости от методологии расчёта, хранение данных в собственных дата-центрах Internet Archive обходятся в 2−5 раз дешевле, чем в облаке. И это только хранение. Сложно даже посчитать, сколько будет стоить круглосуточный исходящий трафик 60 Гбит/с на AWS. Вероятно, он обойдётся даже дороже, чем хранение 200 петабайт.

Похоже, что некоторые сервисы просто «слишком велики» для облака. Компаниям приходится поднимать собственные дата-центры, потому что у них нет выхода. Другой вопрос: должна ли библиотека заниматься этим самостоятельно? Получается, что современная цифровая библиотека — это по сути хостинг-провайдер и дата-центр?


На правах рекламы

Эпичные серверы — это надёжные VDS на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!

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