Клонировать репозиторий во время развертывания на Heroku

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

  1. клонировать PROJECTX-config,
  2. удалить текущие файлы конфигурации и
  3. файлы конфигурации символической ссылки на файлы конфигурации PROJECTX

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

Спасибо!


ruby-on-rails heroku heroku-cli heroku-toolbelt
person Paritosh Singh    schedule 10.09.2017    source источник
comment
Нет - вместо этого используйте env vars. Heroku имеет эфемерную файловую систему, поэтому вы не можете ссылаться на другие репозитории.   -  person max    schedule 10.09.2017
comment
@max Я не могу использовать переменные среды для всех config. Также я считаю, что конфигурация приложения не должна присутствовать в переменных окружения, так как ее утомительно поддерживать, а не поддерживать файл.   -  person Paritosh Singh    schedule 10.09.2017

Ответы (1)


arrow_upward
2
arrow_downward

Нет, это невозможно.

Каждый dyno получает свою собственную эфемерную файловую систему со свежей копией самого последнего развернутого кода. В течение срока службы динамометрического стенда его запущенные процессы могут использовать файловую систему в качестве временного блокнота, но никакие записанные файлы не видны процессам в любом другом динамометрическом стенде, и любые записанные файлы будут удалены в момент остановки или перезапуска динамометрического стенда. Например, это происходит каждый раз при замене динамометра в связи с развертыванием приложения и примерно раз в день в рамках обычного управления динамометром.
- https://devcenter.heroku.com/articles/dynos#эфемернаяфайловаясистема

Или, по крайней мере, не без машины Руба Голдберга, такой как setupe, где вы настраиваете какую-то автоматизацию (например, хук после фиксации), чтобы объединить репо A и репо B и отправить результат в героку.

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

Heroku здесь не согласен.

Традиционный подход к обработке таких переменных конфигурации заключается в том, чтобы поместить их в исходный код — в какой-либо файл свойств. Это подверженный ошибкам процесс, который особенно сложен для приложений с открытым исходным кодом, которым часто приходится поддерживать отдельные (и частные) ветки с конфигурациями, специфичными для приложения.
Лучшее решение — использовать переменные среды и хранить ключи в открытом доступе. кода. На традиционном хосте или при работе локально вы можете установить переменные среды в файле bashrc. В Heroku вы используете переменные конфигурации. - https://devcenter.heroku.com/articles/config-vars

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

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

Если вы все еще думаете, что использование графического интерфейса — это ужасно, используйте файлы YAML, которые вы анализируете и используете для установки переменных ENV:

require 'yaml'

yaml = YAML.load_file(File.join(__dir__, 'conf.yml'))

def create_key(*components)
  components.join('_').upcase
end

env_vars = yaml["production"].each_with_object({}) do |(key,value), memo|
  key_components = [key]
  if value.kind_of? Hash
    value.each_pair do |k,v|
      memo[create_key(*key_components.dup.push(k))] = v
    end
  else
    memo[create_key(*key_components)] = value
  end
end.each do |k,v|
  system("heroku config:set #{k}=#{v}")
  puts "Setting #{k} = #{v}; #{ $? }"
end

Или вы даже можете хранить сериализованную форму (JSON или YAML) в одной переменной окружения — хотя общий размер ограничен 32 КБ.

person max    schedule 10.09.2017