Что такое никсы это линукс

Обновлено: 05.07.2024

Собственно по мотивам ТЫЦ но про NixOS и на основе моего опыта эксплуатации сабжа в течение как минимум одного года восьми месяцев и двух дней или шестьсот двенадцати дней кому как угодно. Ибо именно столько у меня стоит NixOS основной системой тыц.

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

Так вот последние два абзаца написаны собственно только ради того что… Да детки в NixOS таких проблем нет. И быть не может by design. И я скромно умалчиваю про другие архитектуры, контейнера, FHS environment и прочие побочные плюшки.

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

Дальше сам процесс разработки. Про генту я скромно умолчу. А вот NixOS разрабатывают на гитхабе открыто, свободно и без бюрократии и 1770 запросов на слияние и 3753 проблемы тому доказательство.

Я скажу так в генте для меня всегда была головной болью настроить gnome/kde/plasma. Полные метапакеты натащат столько что ппц а минимальные как правило просто обрезаны по самое немогу и для комфортного существования приходилось искать ту самую золотую середину самостоятельно. В NixOS просто дефолтный выбор мне что называется зашел на ура. Одной проблемой меньше.

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

В NixOS пакетный менеджер заведует не просто версией хромиума но и всеми его настройками и да даже его расширениями.

Любые нативные игрушки steam-run спасает и делает не просто хорошо а прям прекрасно.

Ну и покамест на этом всё. Надеюсь мои многобукав помогут кому нибудь сделать свой выбор.

NixOS — это дистрибутив Linux, построенный вокруг двух ключевых идей:

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

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

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

Все это возможно благодаря пакетному менеджеру Nix. В классических дистрибутивах Linux пакетный менеджер при установке пакета «размазывает» его содержимое по всей системе: запускаемые файлы в /usr/bin , библиотеки в /usr/lib , остальные компоненты — в /usr/share . В результате ты получаешь проблемы с неудачным обновлением/удалением пакетов (когда могут остаться файлы-сироты), ад зависимостей (когда два приложения требуют разные версии /usr/lib/libjpeg.so , например) и легкий способ уничтожить всю систему, неудачно обновившись.

Пакетный менеджер Nix размещает все установленные пакеты в собственных подкаталогах внутри каталога /nix/store . К примеру, установленный пакет Git будет располагаться в каталоге /nix/store/nawl092prjblbhvv16kxxbk6j9gkgcqm-git-2.14.1 , где набор цифр — это хеш, образованный от окружения сборки пакета: файлов исходников, дерева зависимостей, флагов компилятора и другого. Поэтому с помощью Nix можно установить одновременно не только две версии одного приложения, но и даже две разные сборки.

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

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

Устанавливаем

В NixOS нет инсталлятора, но если ты когда-нибудь устанавливал Arch Linux, то у тебя не должно возникнуть проблем. Для начала скачиваем последнюю версию NixOS с официального сайта и записываем ее на флешку:

Затем перезагружаем машину и грузимся с флешки. NixOS встретит тебя приветствием командной строки.

Первое, что мы должны сделать, — подготовить диск для установки. Проще всего сделать это с помощью parted (в данном примере мы создаем один большой раздел ext3 на диске с разметкой в стиле DOS):

Мы будем ставить систему на зашифрованный диск, поэтому для начала инициализируем шифрование:

Затем примонтируем диск к каталогу /mnt:

Теперь обновляем репозитории:

И генерируем дефолтовые файлы конфигурации:

Команда сохранит на диск два файла: configuration.nix и hardware-configuration.nix . Первый — это и есть тот самый файл описания состояния системы, с которым мы будем работать в дальнейшем. Содержимое второго изменять не надо — оно создается автоматически на основании железа, на которое устанавливается NixOS.

Наконец, устанавливаем систему и перезагружаемся:

Устанавливаем NixOS

Configuration.nix

Файл configuration.nix — основа дистрибутива. В нем пользователь указывает всю желаемую/необходимую конфигурацию (состояние) системы от пользователей и пакетов до шрифтов и в любой момент может ее изменять. Система будет выглядеть ровно так, как ее опишет пользователь в этом файле.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Мы в Typeable хотели опубликовать небольшой цикл статей о том, как Nix нам помогает (и немного мешает) в разработке. Но, проведя немножко времени в поисках похожего материала здесь, с удивлением обнаружили, что на Хабре нет толкового введения в Nix, на которое можно было бы сослаться.

Статья от @snizovtsev подойдёт как хорошее введение при разработке на C++, но это не совсем то введение, которое мне хотелось бы видеть. Поэтому я решил написать его сам :)

Файлы к этой статье можно найти здесь.

Где это всё взять?

Помимо NixOS, где ничего делать не нужно, Nix можно установить на любой (или почти любой) дистрибутив Linux. Для этого достаточно запустить следующую команду:

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

Язык Nix

Когда речь идёт о Nix, часто имеют в виду две разные сущности: Nix как язык и nixpkgs как репозиторий пакетов, в том числе составляющий основу NixOS. Начнём с первого.

Nix — функциональный ленивый язык с динамической типизацией. Синтаксис во многом похож на языки семейства ML (SML, OCaml, Haskell), поэтому у тех, кто с ними знаком, особых проблем возникнуть не должно.

Начать знакомство с языком можно просто запустив интерпретатор.

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

Как и в языках, повлиявших на Nix, все функции каррированы.

Помимо примитивных типов, таких как числа и строки, Nix поддерживает списки и словари (attribute sets в терминологии Nix).

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

Директива inherit вносит или "наследует" термин из текущей области видимости и даёт ему такое же имя. Пример выше эквивалентен записи let fac = . in < fac = fac; >.

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

Для загрузки кода из других файлов в Nix есть функция import , принимающая путь к файлу с кодом и возвращающая результат выполнения этого кода.

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

fac.nix с использованием with :

Сборка программ

Сборка программ и отдельных компонентов — это основная функция языка Nix.

В случае работы с пакетами, основным инструментом, про который нужно знать, является Derivation . Сам по себе Derivation — это специальный файл, содержащий рецепт для сборки в машинно-читаемом виде. Для компиляции программы на C, выводящей "Hello World!", derivation выглядит примерно следующим образом:

Как видно, в этом выражении содержится путь к результату сборки, который получится в итоге, а также пути к исходным файлам, скрипту сборки, и метаданные: имя проекта и платформа. Стоит так же заметить, что пути к исходникам начинаются с /nix/store . При сборке, Nix копирует всё нужное в эту директорию, после чего сборка происходит в изолированном окружении (sandbox). Таким образом достигается воспроизводимость сборки всех пакетов.

Разумеется, никто в здравом уме руками писать такое не станет! Для простых случаев, в Nix есть встроенная функция derivation , принимающая описание сборки.

Давайте попробуем разобрать этот пример. Весь файл представляет собой определение функции, которая берёт один параметр — словарь, содержащий поле pkgs . Если оно не было передано при вызове этой функции, используется значение по умолчанию: import <nixpkgs> <> .

derivation — функция, так же принимающая словарь с параметрами сборки: name — имя пакета, builder — сборочный скрипт, src — исходный код, system — система или список систем, под который возможна сборка данного пакета.

writeShellScript — функция из nixpkgs , принимающая имя для скрипта и код и возвращающая путь к исполняемому файлу. Для многострочного текста в Nix есть альтернативный синтаксис с двумя парами одинарных кавычек.

С помощью команды nix build , этот рецепт для сборки можно запустить и получить работающий бинарник.

При запуске nix build , в текущей директории создаётся символическая ссылка result , указывающая на созданный в /nix/store пакет.

Сборка программ, продвинутая версия

derivation — достаточно низкоуровневая функция, на базе которой в Nix построены куда более мощные примитивы. Для примера, можно рассмотреть сборку широко известной утилиты cowsay .

Оригинал скрипта находится здесь.

stdenv — специальный derivation , содержащий правила сборки для текущей системы: нужный компилятор, флаги и прочие параметры. Основное содержимое — гигантских размеров скрипт на баше под названием setup , который и выступает в роле скрипта builder из нашего простого примера выше.

mkDerivation — функция, создающая derivation с этим скриптом и заодно заполняющая другие поля.

Заключение

В этой статье я попытался описать самые базовые части работы с Nix как языком для сборки кода. В следующих статьях я планирую показать, как мы применяем Nix в Typeable, а также как это делать лучше не стоит. Stay tuned!

Также, гораздо более подробное введение в Nix опубликовано на сайте самого проекта под названием Nix pills.

Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.

Для любителей пруфов — welcome.

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

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

1-й юниорский

Начнем с самых азов — забудьте про GUI, только консоль, только хардкор ^_^!

Несколько красивых консолей в xmonad для повышения мотивации.

Наше приключение начинаем с того, что надо добраться до консоли (в случае SSH-подключения мы там будем сразу). Кстати, если вы windows user, вам поможет волшебная программка putty.

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

Давайте посмотрим на структуру файловой системы.

Да, не пугайтесь, привычных C: и D: тут нету, всё идет от корня (/).

/	Корневая директория, содержащая всю файловую иерархию.
/bin/	Основные системные утилиты, необходимые и в однопользовательском режиме, и при обычной работе всем пользователям (cat, ls, cp).
/boot/	Загрузочные файлы (в том числе, файлы загрузчика, ядро и т. д.). Часто выносится в отдельный раздел.
/dev/	Основные файлы устройств системы (например, физические устройства: sata-винчестеры /dev/sda, видеокамеры или TV-тюнеры /dev/video или псевдоустройства, например, «черные дыры» /dev/null, /dev/zero).
/etc/	Общесистемные конфигурационные файлы и файлы конфигурации установленных программ (имя происходит от et cetera).
/home/	Содержит домашние директории пользователей, которые, в свою очередь, содержат персональные настройки и данные пользователя. Часто размещается на отдельном разделе.
/lib/	Основные библиотеки, необходимые для работы программ из /bin/ и /sbin/.
/media/	Точки монтирования для сменных носителей (CD-ROM, DVD-ROM, flash-диски).
/opt/	Дополнительное ПО.
/proc/	Виртуальная файловая система, представляющая состояние ядра операционной системы и запущенных процессов в виде каталогов файлов.
/root/	Домашняя директория пользователя root.
/sbin/	Основные системные программы для администрирования и настройки системы, например, init, iptables, ifconfig.
/tmp/	Временные файлы (см. также /var/tmp).
/usr/	Вторичная иерархия для данных пользователя; содержит большинство пользовательских приложений и утилит, используемых в многопользовательском режиме. Может быть смонтирована по сети только для чтения и быть общей для нескольких машин.
/var/	Изменяемые файлы: файлы регистрации (log-файлы), временные почтовые файлы, файлы спулеров.
/var/cache/	Данные кэша приложений. Сюда скачиваются пакеты перед установкой в систему, здесь же они какое-то время хранятся.
/var/lib/	Информация о состоянии. Постоянные данные, изменяемые программами в процессе работы (базы данных, метаданные пакетного менеджера и т. п.).
/var/log/	Различные файлы регистрации (log-файлы).
/var/www/	Директория веб-сервера Apache, всё, что находится внутри, транслируется им в интернет (конфигурация по умолчанию)

Теперь мы узнали, как выглядит файловая система *nix.

Nano

MCEdit

Чип и Дейл спешат на помощь! В любой непонятной ситуации вводите man %commandName%, и восхитительная утилита man в *nix-системах вам расскажет как работает та или иная команда (программа) в bash.
Если вы потерялись в файловой системе, поможет команда pwd.

Теперь давайте обозначим еще некоторые особенности этого семейства OS.

*nix-системы отличаются регистрозависимостью т. е. file.txt и File.txt — разные файлы. И директории /uploads и /Uploads — тоже разные директории.

Еще несколько важных отличий:

В PHP-разработке для ликвидации этих проблем кроссплатформености рекомендуется использовать PHP_EOL для новой строки в консоли и DIRECTORY_SEPARATOR для правильных слешей.

Основное отличие *nix-систем — их многопользовательский подход. Из этого следует логический вывод: если есть много пользователей, надо разграничивать их сферы влияния. Один из основных инструментов для этого — права к файлам и директориям.

Обозначения прав идут в буквенном или цифровом формате.

Увидеть права мы можем через команды ls -l или ls -la, а поменять — через chmod.

Нашел потрясающую картинку, которая объясняет всю суть происходящего.

Добавлю, что в жизни веб-разработчика всегда нужно помнить о правах в linux, поскольку имеет место обыденная ситуация: разрабатывали под windows, задеплоили и внезапно (!) ничего не работает. В целом ничего страшного в них нету, но keep in mind.

P. S. Советую хорошо разобраться в этом моменте, поскольку ставить 777 на весь проект тоже не очень секьюрно.

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

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

Сначала проверяем, что у нас с ОЗУ, для этого подойдет top/htop.

Давайте также вспомним замечательную тулзу — ps. Она выводит отчет о работающих процессах. Удобна еще и несколькими триками:

Удобно пользоваться конвейером и утилитой less для пролистывания выводимой информации с помощью кнопок «вверх» и «вниз», например, ps aux | less.
С помощью утилиты grep удобно искать и выводить только нужные процессы, например, ps aux | grep node.

Для проверки, сколько свободного места у нас на харде, есть команды: df -h и df –k.

Если проблема в ОЗУ, смотрим, что у нас потребляет больше, чем надо, и делаем kill, или же, если это нужные процессы, — думаем дальше :).

В целом на этом можно и закончить первую степень посвящения, но обрадую немного тех, кто очень боится консоли: есть консольный 2-панельный классический файловый менеджер — Midnight commander.

Не знаешь, зачем оно и как работает — не удаляй!
Увидел файл или папку, которые начинаются с точечки — тем более не удаляй ^_^!

2-й юниорский

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

Следующая повседневная задача — установка lamp (linux apache php mysql)-сервера.

Конечно же, нам пригодятся Virtual Hosts. Файл хостов находится по адресу /etc/hosts, а хосты надо редактировать под рутом.

Пришло время упомянуть базовые команды Apache.

Включаем модули в apache, в том числе, модуль PHP (если ставим руками) — a2enmod %moduleName%.
Рестарт сервера — sudo service apache2 restart.

Хосты, которые настроены и существуют (но не факт, что включены!) лежат отдельными файликами в папке /etc/apache2/sites-available. А хосты, которые используются и активны в данный момент, лежат симлинками в папке /etc/apache2/sites-enabled.

In real life выглядит все так: мы создаем файл конфига для нового хоста в sites-available, потом командой a2ensite %hostName% apache создает симлинк в папке sites-enabled, тем самым активируя хост. Обратная процедура — a2dissite.

Когда вы делаете это руками или просто пишете в файл основнового конфига, где-то плачет один котик, ну, или собачка — кому кого больше жаль :).

На уровне php это потенциальный пробел в вашей защите.

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

Сделать так очень просто через htpasswd, вот пример: doc.norang.ca/apache-basic-auth.html.

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

Первое — конфиг живет по адресу /etc/mysql/my.cnf, заходить в гости, как обычно, под рутом.

Перезапустить «моську» можно командой sudo service mysql restart.

Если вы что-то не то сделали с правами своего рута или просто потеряли пароль рута от mysql, сбросить его и задать новый можно командой sudo dpkg-reconfigure mysql-server-5.5 (или 5.6), в общем, подставите нужную версию :).

Перейдем к следующему животрепещущему вопросу в жизни веб-девелопера:

Хоббит SQL-дампы — туда и обратно.
Для бекапа базы в sql-файл используется прекрасная команда mysqldump со следующим синтаксисом:

mysqldump —opt -u [uname] -p[pass] [dbname] > [backupfile.sql]
[uname] Имя юзера
[pass] Пароль (Будьте внимательны между параметром p и паролем нет пробела)
[dbname] Название нашей базы
[backupfile.sql] Как мы называем файл дампа (можно так же указать путь к нему если вы не в той папке где хотите создать его)
[--opt] Дополнительные опции
Пример: mysqldump -u root -p Tutorials > tut_backup.sql

add-drop-table — добавляет в дамп DROP TABLE перед CREATE TABLE.
no-data — дампит только таблицы без контента.
add-locks — добавляет LOCK TABLES и UNLOCK TABLES в дамп.

А если база большая и VPN-коннект не самый быстрый, можно сразу сжать в архив наш дамп следующей командой:

mysqldump -u [uname] -p[pass] [dbname] | gzip -9 > [backupfile.sql.gz]

Теперь давайте разберем накатку базы (условие: базы не существует, накатка с нуля).
Основной синтаксис будет такой:

mysql -u [uname] -p[pass] [db_to_restore] < [backupfile.sql]

Следуя нашему примеру, получаем что-то в духе:
mysql -u root -p Tutorials < tut_backup.sql

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

gunzip < [backupfile.sql.gz] | mysql -u [uname] -p[pass] [dbname]

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

mysqlimport -u [uname] -p[pass] [dbname] [backupfile.sql]

С архивом по аналогии.

Следующий важный момент в MySQL — права Grants. «Моська» у нас многопользовательская, если есть много пользователей, значит, права свои у них будут — life is cruel :). Советую о них почитать. Самая распространенная задача — открыть юзеру вход не с локалхоста Она решается следующим образом:

Удаляем строку bind-address 127.0.0.1 из главного конфига.
Потом выполняем следующие команды:

Здесь database — база данных, к которой назначаем права пользователю username с паролем password, а % указывает на то, что пользователь может прийти не только с локалхоста, а откуда угодно.

Node JS мы также можем установить в две команды “sudo apt-get install nodejs” “sudo apt-get install npm”.
Node-проекты заводить обычно легко, что-то в духе node server.js
Хочу поделиться интересной тулзой nodemon — она дает нам намного больше возможностей в области девелопмента на nodeJS, т. к. следит за изменениями в файлах проекта и перезапускает сервер автоматически:
nodemon.io

Далее рекомендую ознакомиться с работой в консоли самых популярных в мире web development VCS — git и svn. Мануалов по ним очень много разных и хороших, думаю, подберете на свой вкус ;).

3-й юниорский

Вот мы и подобрались к 3-му юниорскому! Довольно неплохой уровень, после которого уже идет хардкор, но тут еще ничего страшного тоже нет, всё достаточно интересно и весело.

Начинается опыт реального подъема серверов с фулстеком (lamp + ftp(s) + ssh) по ситуации, с прикруткой CI-систем, также интересен опыт подъёма хостинг-систем типа Virtualmin / WebMin.
В реальной эксплуатации не рекомендуется оставлять чистый ftp-сервер, лучше использовать SFTP (ftp over ssh) для секьюрности.

Хороший левел — знание vim или emacs. Очень холиварная тема, но не упомянуть нельзя.

Если временами вы очень скучаете по некоторым программам из windows, или у вас есть специфичный софт, который все-таки нужен и аналог никак не можете найти (что же такое страшное вам нужно?!), есть wine — wine is not an emulator.

IE В Ubuntu («работает» еще веселее, чем в нативной среде обитания).

Давайте затронем сетевую тему, первым в гостем нашей студии станет netstat (network statistics), встречайте! Тулза поможет нам посмотреть статистику сетевой активности, открытые порты, наши сетевые интерфейсы и т. д.

И в заключение сетевой темы давайте позовем нашего хедлайнера — nmap. Поприветсвуем гостя nmap!

Очень известная утилита в области сетевой безопасности, видеть ее мы могли в десятках фильмов ;).

Спасибо nmap за столь увлекательную историю и счастливое детство.

Предлагаю перейти на немного advanced level MySQL-тюнинга — PIMP MY DB.

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

DB Tuning можно условно разделить на две части:

Оптимизация структуры базы данных (нормализация/денормализация, foreign keys, indexes и т. д.).
Оптимизация настроек сервера DB.
Про оптимизацию структуры базы данных написано немало гайдов и мануалов, и серебряной пули тут не существует. Всегда смотрим на конкретный проект и индивидуальные проблемы. Explain в помощь :).

Добавим в наше приключение немного стильных, модных и молодежных технологий — CI.

Wiki: Непрерывная интеграция (англ. Continuous Integration) — практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.

На практике это очень удобный софт, позволяющий собирать билды, прогонять все виды тестов, делать минификацию js/css, следить за качеством кода, деплоить, итп.

Читайте также: