Записки IT специалиста

Полезная команда tee в Linux

Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.

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

Например:



 command | tee file1.log


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

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



 command1 | tee file1.log | command2


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

По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ -a:

 command1 | tee -a file1.log


Еще один интересный ключ -i, который предписывает игнорировать команды завершения, такие как Ctrl + C.

Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по Ctrl + C, при наличии данного ключа tee продолжит работу и корректно завершит запись в файл.



 ping ya.ru | tee -i ping_ya.txt


Еще один вариант использование tee - это повышение прав для записи в системные файлы. Например:



 sudo echo "строка_текста" > /etc/myconf.conf


Не увенчается успехом, а если сделать вот так, то все получится:



 echo "строка_текста" | sudo tee /etc/myconf.conf


Как видим, tee - простая, но весьма удобная и функциональная команда.

Обжал и стоишь думаешь - а чего оно на работает...

Про танки. Начало

Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.

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

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

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

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

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

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

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

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

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

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

Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.

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

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

Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.

А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.

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

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

И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.

А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…

Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…

И снова про мощность точки доступа

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

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

Чтобы передать какую-либо информацию мы определенным образом искажаем форму волны – этот процесс называется модуляцией. Причем искажаем мы форму не абы как, а строго на определенную физическую величину.

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

Почему? Потому что электромагнитная волна при распространении взаимодействует с другими электромагнитными волнами, что также приводит к взаимным искажениям формы, этот процесс называется интерференцией (вспоминаем школу и круги на воде).

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

В результате при отдалении на некоторое расстояние мы уже не сможем без ошибок демодулировать волну (т.е. расшифровать переданную информацию) и тут нам нужно или усиливать сигнал, или использовать более простую, а следовательно, более медленную модуляцию.

Ну вот же, видите! Сами написали про повышение уровня сигнала. Но на самом деле не все так просто. Мощность сигнала ограничивается регламентированными значениями и если путем некоторых манипуляций мы можем повысить сигнал точки доступа, то уровень мощности оконечных устройств мы повысить не можем. Более того, все официально продаваемые в стране устройства будут соответствовать нормативам на мощность излучения передатчика.

А теперь вспоминаем еще одну аксиому – все решения в беспроводной сети принимает клиент. Клиент – довольно умное устройство и более-менее знает свои способности. И в голове у него есть некая «табличка», где указаны уровни сигнала точки доступа и доступные уровни модуляции.

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

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

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

В первом случае у нас начнутся потери пакетов, звук начнет заикаться, картинка рассыпаться. Во втором все еще хуже, сигнал есть – связи нет.

Как видим, от увеличения мощности стало только хуже. Но и при номинальной мощности может оказаться так, что эфир достаточно зашумлен и устройства начинают использовать медленную модуляцию.

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

Почему это важно? Потому что полоса передачи в беспроводной сети делится на всех и делится по количеству переданных пакетов. И даже один медленный клиент будет влиять на работу более быстрых занимая большее эфирное время. Подробнее мы об этом писали здесь: https://t.me/interface31/4023

Если коротко – уменьшайте мощность, увеличивайте количество точек, других вариантов нет.

Вчера, 28 марта вышел очередной релиз SystemRescue 13 – специализированный дистрибутив на базе Arch Linux для восстановления компьютеров. В новой версии новое ядро 6.18.20, добавлена поддержка bcachefs и серьезно обновлен софт.

В целом нельзя назвать SystemRescue 13 чем-то новым или оригинальным, все те же операции можно сделать и при помощи любого загрузочного диска с любым Linux, но есть один момент.

На данном диске уже собрано все, что вам может понадобиться, поддержка mdadm, LVM, ZFS и различных файловых систем, включая NTFS, а также собраны все необходимые утилиты и добавлена подробная оффлайн справка.

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

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

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

А в документации даже есть отдельный раздел, как сохранить данные с Windows ПК если он не загружается.

Поэтому рекомендуем данный дистрибутив иметь в своем наборе инструментов.

Анекдот на злобу дня

Идет урок. Учительница спрашивает:
— Дети, кем работают ваши папы?

Аня:
— Мой папа — строитель, он построил много красивых зданий.

Петя:
— Мой папа работает в банке, он защищает наши деньги от мошенников.

Ваня:
— Мой папа — водитель автобуса, вовремя всех привозит на работу и домой.

Вовочка:
— Мой папа — стриптизёр в ночном клубе…

Учительница в смущении быстро сменяет тему, а после урока просит Вовочку остаться.

— Вова, у тебя правда отец работает там, где ты сказал?

— Мария Ивановна, ну как я мог перед всем классом признаться, что у меня отец — сотрудник Роскомнадзора?

Что почитать в субботу вечером?

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

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

🔹 BeOS - система опередившая время

Но у нее остались свои последователи, создавший открытую бинарно совместимую с BeOS систему – Haiku, которая ныне вполне себе живет и развивается. О ней в нашей следующей статье.

В ней же мы еще расскажем о ReactOS, еще одном проекте создания бинарно совместимой системы, только уже с Windows. И если Haiku является вполне стабильной ОС, которую можно применять в повседневной деятельности, то ReactOS скорее тестовая площадка, ни о какой стабильности в нем пока речи не идет.

🔹 Haiku и ReactOS - экзотические операционные системы

И напоследок можно почитать про helloSystem – попытку создать аналог macOS на базе FreeBSD.

При этом преследуется не бинарная совместимость, а воспроизведение как можно более точно основных способов взаимодействия c пользователем, заложенных в macOS (UX) чтобы пользователь сразу попадал в привычную среду и мог полноценно использовать накопленный пользовательский опыт.

Начинание смелое, но пока еще далекое от практического применения. Однако посмотреть на него интересно.

🔹 helloSystem или BSD со вкусом яблока

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

🔹 Zenwalk - встреча с динозавром

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

История создания и развития IBM PC

На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.

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

Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.

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

Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.

Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.

Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.

Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.

Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.

У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS

Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.

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

IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.

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

Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.

Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.

Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.

Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.

Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.

А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.

Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.

Явки, пароли, утюги на подоконнике

Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.

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

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

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

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

Ну как так? А вот так, не записали, забыли, не помнили. Но синхронизация – это ерунда, куда хуже снести таким образом какую-нибудь БД или архив. Мало ли чего там может быть.

Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?

Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…

На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.

Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.

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

В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.

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

Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.

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

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

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

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

Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.

А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.

Что думаете по этому поводу вы? Какие подходы используете?

Где лежат пределы уместности Docker. Продолжение

В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.

Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.

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

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

При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.

Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.

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

Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.

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

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

Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.

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

В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.

Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.

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

Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.

Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.

А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.

И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.

Где лежат пределы уместности Docker

Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.

Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.

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

Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.

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

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

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

Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).

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

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

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

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

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

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

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

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

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

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

Продолжение следует.

Быстрая установка Wordpress + PHP-FPM + Caddy с кешированием Redis в Docker

Сегодня заказчик поставил вопрос – а можно ли сделать сайт на Wordpress «нормально», без постоянной свистопляски с версиями PHP и прочего. Потому как не все хостеры предоставляют VPS на свежих версиях системы, а ручное обновление PHP часто приводит к проблемам.

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

В качестве веб-сервера вместо привычного NGINX мы давно выбираем Caddy, за более простую и прозрачную работу с шифрованием, которая снимает с администратора эту головную боль.

Ну и раз мы решили все делать по-современному, то почему бы сразу не добавить объектный кеш на Redis?

В итоге получился такой файл docker-compose.yml:

services:
  db:
    image: mariadb:10.11
    container_name: wp_db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql

  redis:
    image: redis:alpine
    container_name: wp_redis
    restart: always
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

  wordpress:
    image: wordpress:fpm
    container_name: wp_app
    restart: always
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: ${MYSQL_USER}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_REDIS_HOST', 'redis');
    volumes:
      - wp_data:/var/www/html
      - ./php.ini:/usr/local/etc/php/conf.d/php.ini
    depends_on:
      - db
      - redis

  caddy:
    image: caddy:latest
    container_name: wp_caddy
    restart: always
    ports:
      - "80:80/tcp"
      - "443:443/tcp"
      - "443:443/udp"
    environment:
      MY_DOMAIN: ${MY_DOMAIN}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - wp_data:/var/www/html
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - wordpress

volumes:
  db_data:
  wp_data:
  caddy_data:
  caddy_config:

Там же создаем файл с переменными окружения .env:

MYSQL_ROOT_PASSWORD=your_secure_root_password
MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user
MYSQL_PASSWORD=wp_password
MY_DOMAIN=example.com

Файл конфигурации веб-сервера Caddyfile, если для тестирования нужен самоподписанный сертификат, то раскомментируйте опцию tls internal:

{$MY_DOMAIN} {
        #tls internal
        root * /var/www/html
        php_fastcgi wordpress:9000
        file_server

        # Сжатие 
        encode zstd gzip

        # Кэширование статики (картинки, шрифты, стили, скрипты)
        @static {
                file
                path *.ico *.css *.js *.gif *.jpg *.jpeg *.png *.svg *.woff *.woff2 *.webp
        }
        header @static Cache-Control "public, max-age=31536000, must-revalidate"

        header {
                 X-Frame-Options "SAMEORIGIN"
                 X-Content-Type-Options "nosniff"
                 Referrer-Policy "strict-origin-when-cross-origin"
        }
}

И файл кастомных параметров PHP-FPM php.ini, в котором мы переопределили лимиты загрузки файлов и лимит памяти.

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M

Запускаем все это командой:

docker compose up -d

Ждем пока все соберется и поднимется, потом переходим по доменному имени и выполняем стандартную установку Wordpress, чтобы заработал объектный кеш – установите плагин Redis Object Cache и активируйте его.

На этом все, мы получили быстрый и современный Wordpress, который будет всегда использовать последние версии PHP рекомендуемые разработчиками вне зависимости от вашей хостовой системы.

Взлет и падение Novell NetWare

Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.

Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.

Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.

Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.

Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.

Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.

Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).

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

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

В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.

Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.

Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.

Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.

Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.

Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.

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

Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.

Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.

Свежие новости, без комментариев. 🤬🤬🤬