Надо было на сайте подписаться конечно.
Но я на самом деле напишу отдельный пост. К понедельнику не получилось, а вот к четвергу железно в наших планах, вместе с небольшими плюшками.
Не только. Вот взять к примеру пинтерест. Там есть серверная часть и она довольно большая, с огромным количеством узлов, шедулеров, баз данных и всяких прочих воркеров. Там очень классная система подъема серверов на амазоне, написно тонны скриптов и есть большая вики со схемкой как это всё работает. Так представим на минуту, что ребята берут нашу систему, и тогда у них есть всё так же схема, только живая, из под которой можно управлять всем бекендом и анализировать информацию, мониторить систему.
Я считаю что данная система может найти применение как для инди разработчиков, так и для крупных проектов.
Я обязательно напишу вам, как будем интегрировать метеор, для получения бесценных знаний. Сам работал с метеором работал около полугода, но они очень шустро развиваются. Окажете нам помощь в консультациях?
На следующей неделе постараемся открыть доступ просто к конструктору-редактору схем. Будем называть эту версию альфой. Так и бета вот вот не за горами.
Да для экономии времени, мы решили подключить сервис сбора e-mail адресов mailchimp. А он в обязательном порядке решил показывать адрес, введённый мною при регистрации.
Судя вашей логике, в принципе использование виртуальных машин так же обречено на провал, как и облачные сервисы.
Ведь логика всё та же — упростить жизнь и сэкономить время. А по вашим словам получается, что самым идеальным вариантом является построение своего хостинга, саморучно устанавливая сервера в стойки. Можно примеров привести до бесконечности. Просто помню аналогичные холивары на тему облачных сервисов, однако живут и процветают. И более того скажу, есть отличный пример — сервис heroku. Там система push-to-deploy, кстати, довольно распространённая в последнее время. Так что я бы не был бы столь категоричен.
Да тогда просто под каждую конфигурацию писать скрипт придётся. Занимались и этим. При этом всё равно нет никакой визуализации. Вот у меня было в проекте 20+ серверов. Была вики с их списком и с перечнем что и как было на них установлено. Когда проект растёт, а живой проект всегда растёт, приходилось каждый раз при внедрении нового сервиса вспоминать и рисовать в голове схему взаимодействия данных. А так всё наглядно и сразу воспринимаешь весь backend. Так же и средства мониторинга сейчас оставляют желать лучшего, не в плане техническом, а в плане визуализации.
Мы смотрим фильмы с интерфейсами будущего, а сами при этом не понимаем зачем нам визуализация данных. Я предлагаю лучше создавать эти интерфейсы. Пускай методом проб и ошибок, но хоть как то развивать инструменты разработчиков, ведь это помогает быстрее создавать более лучшие продукты.
Можно привести хорошую аналогию между vi и intellij Idea. Например я не считаю что программировать необходимо исключительно в vi. Есть проекты, в которых хорошая IDE заметно ускорит процесс разработки и позволит избежать ошибок. Иногда и мне приходится так делать, хотя в программировать стараюсь в vi. Так же и в случае проекта.
Ну почему же сразу задвинуть. Мы и сами используем терминал. Я например программирую исключительно в vi. Да и даже в tmux powerline настраивал, что бы spotify треки мне там рисовал. Это прикольно, но извините, деплоить и обновлять с десяток серверов, уже поднадоело.
Всё верно. Heroku это довольно удобно для развёртывания системы. Мы взяли за элемент как раз таки суть dino контейнера. Так-же добавляем сервисы и ко всему прочему логи и мониторинг + визуализация. Вот и в 2х строчках половина сервиса.
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ведь можно скрипты тюнинга прикрутить к элементу? Я же отписал выше —
Мы даже предусмотрели возможность подгружать конфиг файлы.
Для дампов есть специальный раздел настроек сервисов баз данных.
Я не говорю что мы не предусмотрели все нюансы. Эта статья как раз и написана для того что бы их собрать и учесть. Однако, наверное вы упустили одну маленькую деталь: Вы не собираете схему из серверов — вы собираете схему из сервисов, каждый из которых может уникально настраиваться. И наша задача сделать полезный инструмент, которым может пользоваться любой — от разработчика до администратора, до ассистента тех поддержки и мониторинга.
Поэтому и ЗБТ. Был бы рад получить ваши пожелания и рекомендации, я думаю помогли бы учесть некоторые нюансы.
PS
Однако я бы не держал php сервис на одной машине с реляционной бд… судя по вашему скрипту… Потому что как то странно, то тюним на уровне ОС и БД, то саму БД вместе с аппликейшеном держим. Хотя справедливости ради я не знаю что они выполняют. Но выглядит странно.
Согласен с вами что существуют системы в которых без напильника не обойтись, однако не все системы такие уж страшные. К примеру можно разобрать деплой системы из комментария выше. Всё просто есть балансер nginx, node.js, mongo.
Чем не простая реальная система?
Ну допустим вы первым делом, будете поднимать окружение для node.js, затем будете поднимать сервер с монгой. Неужели на этапе создания прототипа вы будете писать «кастомный скрипт немалого размера»? Вряд ли! На данном этапе вам надо быстро подготовить окружение для разработки, что бы начать работать.
Далее, когда всё готово к продакшн запуску, необходим тюнинг. Только и на этом этапе, что вы будете например править в конфигах nginx, или в node.js, когда всё и так работает? Никто не говорит что тюнинг не нужен — наоборот! Он даже необходим. Поэтому мы даём возможность настроить каждый элемент схемы. Каждый элемент схемы имеет свой, присущий ему набор конфигураций. Мы даже предусмотрели возможность подгружать конфиг файлы.
Может быть есть какие то специфические места, которые присущи проектам с которыми вы работаете, я бы с удовольствием учёл бы этим моменты при разработки системы.
Но я на самом деле напишу отдельный пост. К понедельнику не получилось, а вот к четвергу железно в наших планах, вместе с небольшими плюшками.
Я считаю что данная система может найти применение как для инди разработчиков, так и для крупных проектов.
Ведь логика всё та же — упростить жизнь и сэкономить время. А по вашим словам получается, что самым идеальным вариантом является построение своего хостинга, саморучно устанавливая сервера в стойки. Можно примеров привести до бесконечности. Просто помню аналогичные холивары на тему облачных сервисов, однако живут и процветают. И более того скажу, есть отличный пример — сервис heroku. Там система push-to-deploy, кстати, довольно распространённая в последнее время. Так что я бы не был бы столь категоричен.
Мы смотрим фильмы с интерфейсами будущего, а сами при этом не понимаем зачем нам визуализация данных. Я предлагаю лучше создавать эти интерфейсы. Пускай методом проб и ошибок, но хоть как то развивать инструменты разработчиков, ведь это помогает быстрее создавать более лучшие продукты.
Можно привести хорошую аналогию между vi и intellij Idea. Например я не считаю что программировать необходимо исключительно в vi. Есть проекты, в которых хорошая IDE заметно ускорит процесс разработки и позволит избежать ошибок. Иногда и мне приходится так делать, хотя в программировать стараюсь в vi. Так же и в случае проекта.
Ведь можно скрипты тюнинга прикрутить к элементу? Я же отписал выше — Для дампов есть специальный раздел настроек сервисов баз данных.
Я не говорю что мы не предусмотрели все нюансы. Эта статья как раз и написана для того что бы их собрать и учесть. Однако, наверное вы упустили одну маленькую деталь: Вы не собираете схему из серверов — вы собираете схему из сервисов, каждый из которых может уникально настраиваться. И наша задача сделать полезный инструмент, которым может пользоваться любой — от разработчика до администратора, до ассистента тех поддержки и мониторинга.
Поэтому и ЗБТ. Был бы рад получить ваши пожелания и рекомендации, я думаю помогли бы учесть некоторые нюансы.
PS
Однако я бы не держал php сервис на одной машине с реляционной бд… судя по вашему скрипту… Потому что как то странно, то тюним на уровне ОС и БД, то саму БД вместе с аппликейшеном держим. Хотя справедливости ради я не знаю что они выполняют. Но выглядит странно.
Чем не простая реальная система?
Ну допустим вы первым делом, будете поднимать окружение для node.js, затем будете поднимать сервер с монгой. Неужели на этапе создания прототипа вы будете писать «кастомный скрипт немалого размера»? Вряд ли! На данном этапе вам надо быстро подготовить окружение для разработки, что бы начать работать.
Далее, когда всё готово к продакшн запуску, необходим тюнинг. Только и на этом этапе, что вы будете например править в конфигах nginx, или в node.js, когда всё и так работает? Никто не говорит что тюнинг не нужен — наоборот! Он даже необходим. Поэтому мы даём возможность настроить каждый элемент схемы. Каждый элемент схемы имеет свой, присущий ему набор конфигураций. Мы даже предусмотрели возможность подгружать конфиг файлы.
Может быть есть какие то специфические места, которые присущи проектам с которыми вы работаете, я бы с удовольствием учёл бы этим моменты при разработки системы.