Задать вопрос
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 просмотров
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 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 приложений
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы
TEYCA Казань
от 150 000 до 240 000 ₽
Netwrk Буэнос-Айрес
от 5 000 до 7 500 $
от 6 000 до 8 000 $