rockysoul
@rockysoul
ruby monkey

Как построить конвейер сайтов на Ruby On Rails? Подходит ли RoR вообще?

Существует компания А, которая разрабатывает сайты для дизайн-студии Б.
Это, чтобы вы понимали 10-20 дорогих сайтов для крупных компаний, но простых по сути. Сложным бывает только эффектныый фронтенд.

Ранее компания имела неплохую, универсальную, самописную CMS на PHP и новый проект просто заливался на FTP. Все безнадежно устарело и PHP надоел людям. Ну и в общем так себе процессы были.

Сейчас есть идея значительно улучшить стек, полностью отделить бекенд разработку от фронта и перейти на Rails ( я пишу на рельсах 4 года), в связи с чем вопрос: как построить близкий по своей простоте конвейер с такими требованиями:

  • разработчики не тратят время на создание нового проекта и деплой изменений (или почти не тратят)
  • дешевые сервера или сервисы (сейчас php сервер обходится в копейки, хайлоады не рассматриваем — их нет)
  • хорошо бы если не требовались бы услуги девопса, но не критично. Хотя бы очень редко чтобы.


Я вижу себе какой-то Digital Ocean, Travis, Github и Docker. Но это пиндец как сложно новичкам дается. Можно ли как-то еще упросить?

Важный подвопрос: есть ли альтернативы получше? Node.js?
  • Вопрос задан
  • 814 просмотров
Пригласить эксперта
Ответы на вопрос 4
Matvey-Kuk
@Matvey-Kuk
Разработчик в Cisco, CA.
Настраивал конвейер для полностью аналогичной компании пару лет назад. Единственное отличие - почти не было PHP наследия.

За основу взял Django стек, т.к. он отлично подходил по количеству свободных профессионалов на рынке и тем, что в Django "всегда есть единственный очевидный путь как сделать что-либо правильно", тогда как в Node этих путей очень много и каждый новый нанятый программист должен чуть-чуть, да изменять свои подходы к разработке.

Поначалу основной упор пришлось таки сделать на DevOps, все работало на GitLab, GitLab CI, Docker и хостинге Flops.ru. Это очень муторная, долгая работа по первичной настройке всего и вся. Не уверен, что её получится избежать.

Разработка проекта велась следующим образом:
1) Есть репозиторий с "заготовкой", копируется в новый репозиторий.
2) Подключается GitLab CI, в переменных среды задается вся-вся конфигурация. Например, на каких серверах запускать, на каких доменах и так далее.
3) Программисты выпинываются на прогулку по другим репозиториям в поисках удачных технических решений в похожих проектах.
4) Пушат код, он заливается на сервачки. Каждая ветка - на свой поддомен, фичи тестятся отдельно. Кодревью, Юниттесты, Мерж реквесты - это все реально помогает.

В итоге когда все завелось и начало помогать, а не делать больно (примерно через пол года), появилась другая проблема - как нам то же самое соорудить на фронтенде? А это уже совсем другая история...
Ответ написан
Singaporian
@Singaporian
Так, давайте отделим мух от котлет.

Задач я тут вижу две:
  1. Какую платформу использовать
  2. Как деплоить

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

Итак,
1: Выборов три:
  1. a. Server lease (когда вы просто арендуете конкретный выделенный или виртуальный сервер у провайдера)
  2. b. IaaS (например, AWS EC2) - то же самое, что "1.a", но можно мгновенно создавать и удалять
  3. c. PaaS (например, AWS BeansTalk, OpenShift, CloudFoundry) - когда вы вообще абстрагированы от понятия "сервер" и оперируете понятиями "ресурс".

Выбор тут основывается на вашем кошельке (чем ниже - тем дороже) и знаниях (чем ниже - тем проще).

2: Пришло время деплоить.
Если у вас PaaS, то вопрос деплоя хорошо покрыт в их инструкциях - и у каждого по своему.
Если у вас сервер, то лучше деплоить докером (а точнее docker compose). Делается это следующим образом. Сначала разбиваете свой сервис на максимально атомарные микро-сервисы.
Например, у вас получились: само приложение (RoR + sidekiq), PostgreSQL, Redis.
Соответственно, вы делаете три контейнера. Все три контейнера вы описываете в в файле docker-compose.yml
Но тут есть одно но. В то время, как PostgreSQL и Redis вы можете взять стандартные - и эти контейнеры уже готовы, то свой RoR вам нужно каждый раз доделывать. Ведь в нем могли измениться зависимости или что-то еще. Поэтому в docker-compose.yml вы один из контейнеров описываете со словом "build ." - это значит, что docker compose не будет пытаться его стягивать из интернета, а найдет файл Dockerfile и, согласно ему, построит имедж самостоятельно. А уже в этом имедже будет что-то типа:

# Please keep same version as in Gemfile (https://hub.docker.com/r/library/ruby/)
FROM ruby:2.3.4

ENV RACK_ENV development

COPY . /usr/share/website

WORKDIR /usr/share/website
RUN bundle install

CMD ["/usr/share/website/run_rails.sh", "/usr/share/website"]


В файле run_rails.sh будет что-то типа:
#!/bin/bash

cd $( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
export RACK_ENV=development
export SECRET_KEY_BASE=266a11dc19acc67107064dfddcecb4187545a08b35bd9a847c7b53545be22dbd8d115036024fcfc659f5936ba4a5df9a7d2a937797fv9d7v9fv7v97e9f430ff

bundle install

bundle exec rake db:migrate db:seed
bundle exec rake assets:precompile

find /usr/local/bundle -name guard
bundle exec foreman start --procfile Procfile.dev --port 8080


А сам docker-compose.yml будет похож на:
version: '3'

services:
    pg:
        image: postgres:9.6
        environment:
            - PGDATA=/var/lib/postgresql/data
            - POSTGRES_DB=project_db_dev
            - POSTGRES_USER=project_user
            - POSTGRES_PASSWORD=project_password
        volumes:
            - ${PG_DATA_DIR}:/var/lib/postgresql
        ports:
            - 5432:5432

    rd:
        image: redis:4.0
        ports:
            - 6379:6379

    ws:
        build: .
        volumes:
            - .:/usr/share/website
        ports:
            - 8080:8080
        depends_on:
            - pg
            - rd

Обратите внимание, что данные PostgreSQL находятся не на самом имедже - иначе их можно потерять при обновлении или удалении сервера.

Вот и вся ваша проблема.
Ответ написан
Комментировать
saintbyte
@saintbyte
Django developer
Деплоить можно по средствам capistrano , серваки разворачивать ansible
Ответ написан
@Mox
Team Lead, RoR, React/React Native
Я обратил внимание, что при старте нового RoR проекта есть ряд рутинных действий, которые можно автоматизировать

Например
- Подключить БД
- Подключить Capistrano
- Подключить всякие служебные gem вроде Nokogiri, Russian, Paperclip, Sorcery
- Подключить front библиотеки

Можно написать простой скрипт - генератор приложения, который будет создавать новое приложение уже сразу с библиотеками (и может быть даже контроллерами и типовыми routes), принятыми в вашей компании

Сейчас думаю про такой для React Native приложений
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы