This year shouldn’t be an exception to write a post to keep the ancient technology alive. Did a transformation, so this website is running inside the docker container that is built from the actual pipeline. The site still uses Apache, still runs CGI with Parser3 and performs XSLT (I know, it’s indefinite source of security issues) as it was in 2005.

But … let me keep this piece of tech up and running for archeology purposes.

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

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

Все сервера тогда администрировались вручную, никакого особо Infrastructure as a Code не просматривалось. Нужно было поднять FTP, Apache, дать права на каталоги чтобы пользователи не видели друг друга. Создать типовую структуру каталогов, типа html, logs, etc. Создать правильные .htaccess с настройками для PHP и других языков. PHP и Parser не умели работать в виде daemon, поэтому хорошей практикой было загружать бинарник прямо в каталог и прописывать его как обработчик в .htaccess. Сейчас любой бы с точки зрения безопасности покрутил бы пальцем у виска.

Ах да, бэкапы. Какие бэкапы? Их скорее не было чем было. Если руки доходили, то один веб-сервер бекапил на другой веб-сервер. 

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

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

Подумайте, сможете ли вы запустить ваш сайт на React 17 и NodeJS 20 через 10 лет, если обратная совместимость не будет в приоритете, а ни одной вам так нужной зависимости вы не сможете скачать?

Вот так и мой опыт с этим сайтом. Он был написан в 2005 году на коленке на вполне маргинальной технологии Parser3 от студии Лебедева. В то время еще не придумали докеризацию и самым популярным браузером был Apache 2.

С тех пор много воды утекло, Apache 2 все также можно установить, Parser3 появился в Debian пакетах. MySQL теперь версии 8, пятерка уже не поддерживается.

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

Потратил полтора дня чтобы докеризировать все это дело и инициализировать строку подключения к базе данных. Заодно настроил CI/CD в Drone и деплоймент в собственный кластер Hashicorp Nomad на Хетцнере.  Однако, результатом доволен.

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

Да, я все еще могу зайти и увидеть редактор TinyMCE, жду когда интернет окончательно сломает Javascript. Что будет с rich applications которые сегодня создаются?

NextJS куда денется?

Дайте побыть нестарым дедом. Что с технологиями? Почему они не становятся надежнее и быстрее? Наоборот, что бы индустрия поглощала новых кандидатов не из ИТ бекграунда, нужно делать разработку "проще". Что и происходит на наших глазах. 

Сегодня я уже не стал бы использовать те же технологии для персонального сайта. Наверное что-то сделал бы на Netlify и/или использовал хостинг GitHub.

Ушла эпоха. Этот сайт теперь музейный экспонат. Будет жить пока я поддерживаю жизнь в хостинге.

 За что и выпьем. 

Мне очень понравился формат итогов на этом сайте https://blog.fogus.me/2021/12/27/the-best-things-and-stuff-of-2021/

Что было запланировано в прошлом году, что достигнуто и что нет.

Список людей, которые вдохновили. Это все надо собирать куда-то, что бы было что потом предъявить. 

Для этих целей у меня есть Емакс и org-roam. Обязательно сделаю также в следующем году.

Хорошая технология это такая технология, которую запускаешь через 15 лет, а она еще работает.

Так и этот сайт, один из последних в категории "домашняя страница", таких давно уже не делают. Здесь целый пучок странных технологий, которые, пожалуй уже никто и не использует. Parser3 студии Лебедева, XML и шаблоны на XSLT!

Сайт без SSL, прости хоспади, очень-очень небезопасный. Гугл такие перестал любить лет 5 назад. А нет, поди ж ты, работает. 

Не секрет, что продукты, разработанные на Ruby on Rails представляют собой жесть при установке. Разные версии ruby, разные версии конфликтующих gem и все такое делают жизнь тяжелее и грустнее.

 Пока не появился docker. Docker это чудо. Это Git для файловой системы.При помощи Docker установка gitlab или redmine становится почти тривиальной. 

Я попробую объяснить что такое Docker "на пальцах". Во-первых проще всего понять docker если рассматривать его как эдакую виртуализацию. Во-вторых docker имеет инструментарий для связывания одного виртуального окружения с другими окружениями. В-третьих это реализация концепции "одна роль – один сервер". В случае докера замените сервер на "контейнер" и получим "одна роль – один контейнер". Что круто само по себе и имеет ряд интересных эффектов. Один из таких эффектов это возможность передавать на тестирование, в продакшен или еще куда наше веб-приложение, которое уже установлено и гарантированно работает так же как и у разработчика. 

Вот несколько концепций, которые вам помогут понять, что такое docker.

1. Docker Image. Образ файловой системы, ее слепок с необходимыми библиотеками и софтом. Скажем, окружение веб-сервера. Вы можете создавать образы самостоятельно или загружать уже готовые, такие как gitlab или redmine.

2. Docker container. Используя образ файловой системы запущенный в памяти (или лежащий незапущенный на диске) производный образ от docker image. Допустим, запущенный веб-сервер.

3. Volume. "Расшаренная папка" между контейнером и хостовой файловой системой.

4. Port. "Проброс портов" или когда сетевой порт хостовой машины соответствует порту контейнера.

5. Link. Линковска это способ взаимодействия контейнеров между собой. Один контейнер ничего не знает про другой, но используя линковку можно ставить переменные окружения, внутренние хосты, которые будут уквзывать на ресурсы второго контейнера. Например, линкуя наш контейнер с контейнером с базой данных мы будем иметь доступ к порту базы данных и IP сервера базы данных из другого контейнера. 

Ниже я опишу установку такой специфичной штуки как gitlab. С docker это сделать очень просто. 

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

Вот пример запуска gitlab в две строки!

wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml

docker-compose up

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

Если у вас не собирается Raid массив автоматически после перезагрузки на XenCenter, поможет такая комманда

 mdadm -Es >> /etc/mdadm.conf

проверяйте после перезагрузки.