Заметка: В этой статье вы увидите, что ZFS повторяется очень много раз. Когда я буду говорить об особенностях и установке, я имею в виду OpenZFS. Пути ZFS (разработанная Oracle) и OpenZFS разошлись, с того момента как Oracle закрыла проект OpenSolaris. (Подробнее дальше в статье.)

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

В статье рассказывается, как сделать статические версии веб-страниц для их выдачи сервером и как поместить их в репозиторий для контроля версий и резервного копирования. При этом статические и медиафайлы могут храниться отдельно и архивироваться другими средствами (статика обычно помещается в репозиторий для программного кода сайта). Метод работает также для страниц с Unicode-именами (например, для кириллических доменов). В конце приведён работающий Makefile.

Автор пользуется стеком django/uwsgi/nginx, виртуальным выделенным сервером под управлением GNU/Linux, но содержание статьи почти не зависит от конкретных технологий.

Казалось бы, тема избитая – про резервное копирование сказано и написано многое, поэтому нечего изобретать велосипед, просто бери и делай. Тем не менее, каждый раз, когда перед системным администратором web-проекта встает задача настроить бэкапы, для многих она повисает в воздухе большим вопросительным знаком. Как правильно собрать бэкап данных? Где хранить резервные копии? Как обеспечить необходимый уровень ретроспективы хранения копий? Как унифицировать процесс резервного копирования для целого зоопарка различного ПО?

В предыдущей статье был описан процесс интеграции ГОСТовых сертификатов КриптоПро с mono. В этой же подробно остановимся на подключении RSA сертификатов.

Мы продолжали переносить одну из наших серверных систем написанных на C# в Linux, и очередь дошла до части связанной с RSA. Если в прошлый раз сложности в подключении легко объяснялись наличием взаимодействия двух, исходно не связанных друг с другом систем, то при подключении «обычных» RSA сертификатов от mono явно никто не ожидал подвоха.

В связи с переходом на Linux возникла необходимость переноса одной из наших серверных систем написанной на C# в Mono. Система работает с усиленными ЭЦП, поэтому одной из поставленных перед нами задач была проверка работоспособности ГОСТовых сертификатов от КриптоПро в mono. Сам КриптоПро уже довольно давно реализовал CSP под Linux, но первая же попытка использования показала, что нативные классы криптографии Mono (аналогичные тем, что есть в базовом .Net — X509Store, X509Certificate2 и проч.) не только не работают с ГОСТовыми ключами, они даже не видят их в своих хранилищах. В силу этого работу с криптографией пришлось подключать напрямую через библиотеки КриптоПро.

$ ./calc "32+6*" # "(3+2)*6" в инфиксной нотации
30

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

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

1. Контейнеры незыблемы: ОС, библиотеки, папки и приложения – поскольку все это хранится прямо в контейнере, вы на 100 % уверены, что в продакшн всегда пойдет именно тот образ, который тестировался в QA. И работать он при этом будет абсолютно аналогично.
2. Контейнеры легковесны: Контейнер не ест память впустую. Вместо сотен мегабайт и гигабайт контейнеру нужна память лишь под основной процесс.
3. Контейнеры быстрые: Контейнер запускается так же быстро, как и обычный Linux-процесс. Не минуты, а буквально считанные секунд.

Это вторая часть истории о портировании шаблонного движка Jinja2 на C++. Первую можно почитать здесь: Шаблоны третьего порядка, или как я портировал Jinja2 на C++. В ней речь пойдёт о процессе рендеринга шаблонов. Или, иначе говоря, о написании "с нуля" интерпретатора питоноподобного языка.

• .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
• Kubernetes для оркестрации микросервисов,
• Docker для создания образов микросервисов,
• шина интеграции Rabbit MQ и Mass Transit,
• Elasticsearch и Kibana для логирования,
• TFS для реализации конвейера CI/CD.

Введение