How to run Rails migrations and seeding in Amazon Elastic Beanstalk single container Docker environment

后端 未结 4 1862
野趣味
野趣味 2020-12-29 12:50

I\'m working on deploying a Rails application to Elastic Beanstalk using docker and so far everything has worked out. I\'m at the point where the application needs to run mi

4条回答
  •  借酒劲吻你
    2020-12-29 13:33

    Solution 1: run migration when you start server

    In the company I work for we have literally equivalent for this line to start the production server:

     bundle exec rake db:migrate && bundle exec puma -C /app/config/puma.rb
    
    • https://github.com/equivalent/docker_rails_aws_elasticbeanstalk_demmo_app/blob/master/puppies/script/start_server.sh.:

    • https://github.com/equivalent/docker_rails_aws_elasticbeanstalk_demmo_app/blob/master/puppies/Dockerfile

    And yes this is Load balanced environment (3 - 12 instances depending on load) and yes they all execute this script. (we do load balance by introducing 1 instance at a time during deployment)

    The thing is the first batch of deployment (first instance up ) will execute the bundle exec rake db:migrate and run the migrations (meaning it will run the DB changes) and then once done it will run the server bundle exec puma -C /app/config/puma.rb

    The second deployment batch (2nd instance) will also run the bundle exec rake db:migrate but will not do anything (as there are no pending migrations). It will just continue to the second part of the script bundle exec puma -C /app/config/puma.rbo

    So honestly I don't think this is the perfect solution but is pragmatic and works for our team I don't believe there is any generic "best practice" for EB out there for Rails running migrations as some application teams don't want to run the migrations after the deployment while others (like our team) they do want to run them straight after deployment.

    Solution 2: background worker Enviromnet to run migrations

    if you have Worker like Delayed job, Sidekiq, Rescue on own EB enviroment you can configure them to run the migrations:

    bundle exec rake db:migrate && bundle exec sidekiq)

    So first you willdeploy the worker and once the worker is deployed then deploy webserver that will not run the migrations

    e.g.: just bundle exec puma

    Solution 3 Hooks

    I agree that using EB hoos ore ok far this but honestly I use eb hooks only for more complex devops stuff (like pulling ssl certificates for the Nginx web-server) not for running migrations)

    anyway hooks were already covered in this SO question so I'll not repeat the solution. I will just reference this article that will help you understand them:

    • https://blog.eq8.eu/article/aws-elasticbeanstalk-hooks.html

    Conclusion

    It's really up to you to figure out what is the best for your application. But honestly EB is really simple tool (compared to tools like Ansible or Kubernetes) No mater what you implement as long as it works its ok :)

    One more helpful link for EB for Rails developers:

    • talk: AWS Elastic Beanstalk & Docker for Rails developers

提交回复
热议问题