dresden-weekly / ansible-rails Goto Github PK

Nice work so far!

I will try to add the following roles in the next couple of days/weeks :)

Sidekiq:

• start workers on system start
• start/restart worker gracefully on deploy
• Best place for this? upstart/sidekiq? or rails/sidekiq?

Cronjobs with whenever

• regenerate crontab for user with whenever (Gem I always use for managing cronjobs)
• Place? rails/whenever?

I was troubleshooting an issue where I'm deploying to a staging environment (I have rails_env set for staging) and found that passenger+nginx was attempting to use production. I ssh'd into the server and manually edited the sites-available/[myapp].conf to add:

passenger_app_env staging;

And now everything is working properly. Is this an nginx config that this role should be setting? Seems like it to me, but maybe I'm missing something. I'd be happy to attempt to add this in a PR, if desired.

Thanks for all your hard work!

I have trouble setting up the user jobs.
Is there some sudo required for the running user to make it work? Didn't find any hints in a README or the puma template. I've included the upstart role with the regarding user as only argument in the users-list.

Starting the newly created job always results in:

$ start worker 
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

$ whoami
podfilter

(same with restart, stop)

Googling that error message always points out to use sudo - but that wouldn't work with the session_init type of user jobs?

contents of ~/.init/worker:

# /etc/init/sidekiq.conf - Sidekiq config
# Ansible managed: /etc/ansible/roles/dresden-weekly.Rails/rails/jobs/sidekiq/templates/sidekiq.conf.j2 modified on 2015-09-29 21:38:51 by stefan on lnxhn04
description "Sidekiq Background podfilter"
start on user-jobs
stop on runlevel [06]
respawn
respawn limit 3 30
normal exit 0 TERM
reload signal USR1
instance /home/podfilter/app/current
script
exec /bin/bash <<'EOT'
  /bin/bash -lc -- '
    cd /var/www/app;
    exec bundle exec sidekiq -i 0 -e production -C /home/podfilter/app/shared/config/sidekiq.yml -L /home/podfilter/app/shared/log/sidekiq.log
  '
EOT
end script

Observations:

• Run file in /var/run/user/UID/upstart/sessions/SOMEID.session exists.
• the session_init and session_init_setup tasks are created, session_init is running with the USER argument:

# initctl list | grep session
session_init_setup stop/waiting
session_init (podfilter) start/running, process 9249

• File syntax of worker.conf is ok:

$ init-checkconf ~/.init/worker.conf
File worker.conf: syntax ok

• Ubuntu 14.04.3 with upstart installed

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS

The current setup only supports the --without option defaulted to testand development. Removing any of the defaults after the command has already been executed once with the defaults has no effect since those options are remembered as by bundle config

Solutions to this might be an explicit --with support or to change the config to disable remembering of those values, if all invocations of bundle are coming from ansible.

For a rather old project i needed ruby 1.8.7 but i quickly discovered that rvm failed to install it, because it tried to compile the sources but was missing the package 'autoconf'. If i find time, i will make a pull request, but for now i just wanted to track it here.

Hello. I've been getting great use out of your collection of ansible playbooks - so thanks! I'm using the Rails/ruby/rvm role in a provisioning script, and everything has been working just fine until I started getting the following error. This is being run on a machine built from the same Vagrantfile I've been using all along. As far as I can tell, it's the same VM, running with the same playbooks in the same order, but this failure just started happened, which admittedly makes no sense.

TASK [dresden-weekly.Rails/ruby/rvm : Import GPG keys] *************************
fatal: [192.168.66.6]: FAILED! => {"failed": true, "msg": "ERROR! The conditional check 'rvm_gpg_keys_check.rc != 0' failed. The error was: ERROR! error while evaluating conditional (rvm_gpg_keys_check.rc != 0): ERROR! 'dict object' has no attribute 'rc'\n\nThe error appears to have been in '/home/vcavallo/development/ansible-rails/roles/dresden-weekly.Rails/ruby/rvm/tasks/gpg_keys.yml': line 13, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Import GPG keys\n  ^ here\n"}
...ignoring

TASK [dresden-weekly.Rails/ruby/rvm : Alternative GPG keys] ********************
fatal: [192.168.66.6]: FAILED! => {"failed": true, "msg": "ERROR! The conditional check 'rvm_gpg_keys_check.rc != 0 and rvm_import_gpg_keys_result.rc != 0' failed. The error was: ERROR! error while evaluating conditional (rvm_gpg_keys_check.rc != 0 and rvm_import_gpg_keys_result.rc != 0): ERROR! 'dict object' has no attribute 'rc'\n\nThe error appears to have been in '/home/vcavallo/development/ansible-rails/roles/dresden-weekly.Rails/ruby/rvm/tasks/gpg_keys.yml': line 21, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Alternative GPG keys\n  ^ here\n"}

Let me know what additional information you need from me, including debug messages or whatever.
Thanks!

It seems the validation for RVM has changed again.

Before we can add any other changes this should be fixed.

If deploying to a staging environment, it is necessary to get the env variable into whenever so it can write the crontab properly.

I'll submit a pull request that accomplishes this for me.

Now that @strfry fixed our Travis Build, we should add a Ubuntu 16.04 test.
We use this for quite a while in production, so it should not be too hard.

What holds us back:

• upstart is always used (replaced with systemd on 16.04)

I've noticed that Gemfile.lock is missing from default git archive command https://github.com/dresden-weekly/ansible-rails/blob/develop/rails/create-release/defaults/main.yml#L19

With a personal app, I just had problems with divergent gem versions production/development. Of course, I can manually add the file to the custom list.

But I think, for most apps it is desired to keep the Gemfile.lock and do not upgrade automatically (AFAIK most apps versions are more relaxed).
I know, with Redmine/ multiplatform deployment, you overwrite Gemfile.lock, but I sense, Gemfile.lock would be a good default.

That, or choosing a different strategy than git archiving (like just copying over the archive).

What do you think @arBmind @tnt ?

When I run rails console (or other rails commands) from the command line, I get this lengthy message

$ bundle exec rails c
Looks like your app's ./bin/rails is a stub that was generated by Bundler.

In Rails 4, your app's bin/ directory contains executables that are versioned
like any other source code, rather than stubs that are generated on demand.

Here's how to upgrade:

  bundle config --delete bin    # Turn off Bundler's stub generator
  rake rails:update:bin         # Use the new Rails 4 executables
  git add bin                   # Add bin/ to source control

You may need to remove bin/ from your .gitignore as well.

When you install a gem whose executable you want to use in your app,
generate it and add it to source control:

  bundle binstubs some-gem-name
  git add bin/new-executable

Loading production environment (Rails 4.2.4)
2.2.0 :001 >

In addition, when quitting that irb session, Rails will exit with a lengthy usage message.

When I run the given commands, Rails c does not start anymore, as the symlinking of the bin folder makes it confused:

$ bundle exec rails c
bin/rails:3:in `require_relative': cannot load such file -- /home/user/app/shared/config/boot (LoadError)
        from bin/rails:3

So it seems, either

• the Rails binstubs don't work with symlinked bin folder, or
• the Bundle binstubs generating that huge warnings.

What is the reasoning behind symlinking bin by default? Somebody else experience that problem?

Overriding rails_deploy_shared_folders and making sure that bin/* is generated by rails fixes that issue for me.

FWIW: Capistrano-bundler decided to remove that bin dir by default: capistrano/capistrano#1321

Following roles use the groups variable to get information about the application host:

• nginx/puma
• nginx/webrick
• rails/create-release
• rails/publish-assets

If the host has an other name this does not work:

TASK [dresden-weekly.Rails/nginx/webrick : Site configuration] *****************
fatal: [*********]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'app'"}

As suggested in eThe tests should be run with all supported Ansible versions.
The current master should support Ansible >= 2.5

Originally posted by @zealot128 in #80 (comment)