Salted _ Rails _ Server
A ruby on rails generator for provisioning a new server using salt-ssh
Supports the following:
- User - User setup
All installations are the latest packages for the managed system unless there is a version section in the pillars/default.sls.
- Ubuntu Trust
- Ubuntu Xenial
No reason this should not work on any other salt stack supported OS. If you have tried this on any other OS and it did not work, please let me know.
This code requires that you have Saltstack's salt-ssh already installed on the system you are deploying from and a compatible version of python on the system you are deploying to. If you are a mac user attempting to use this and you have issues, try using salt-ssh-vm
Consult the following documentation for your OS: https://docs.saltstack.com/en/latest/topics/installation/index.html
Add this line to your application's Gemfile:
And then execute:
And then generate code:
rails g salted_rails_server
The following files will be generated in the root directory:
./master ./roster # DO NOT CHECK IN THIS FILE!!! ./Saltfile ./salt_ssh ├── pillars │ ├── default.sls │ └── top.sls └── states ├── backup │ └── files │ └── home │ └── deploy │ ├── bin │ │ └── backup.rb │ └── config │ └── schedule.rb ├── backup.sls ├── elasticsearch.sls ├── imagemagick.sls ├── logrotate │ └── files │ └── etc │ └── logrotate.d │ └── rails ├── logrotate.sls ├── monit │ ├── etc │ │ └── monit │ │ └── monitrc │ └── redis.sls ├── monit.sls ├── mysql.sls ├── nginx.sls ├── node.sls ├── redis.sls ├── rails.sls ├── rvm.sls ├── setup.sls └── user.sls
Add custom options to the following files:
- roster - remote host(s) information
- pillars/default.sls - RAILS_ENV, Remote Username with ssh-key, MYSQL root and rails user user password and versions of ruby and elasticsearch to be installed.
Setting up Remote system
Add your public ssh key to the authorized_keys on remote server that you plan to manage. I normally add this to root but it needs to be added to a user with sudo privileges.
Testing salt-ssh connection
From within the appliation root directory type:
sudo salt-ssh -i '*' test.ping
The following should be returned:
If that is not returned, salt-ssh should give you an accurate reason to why it was not able to connect. Another tool to use is the verbose option on the ssh command.
ssh -vv user@remote-host
The States (Remote Management)
- user - User setup
The Setup State
sudo salt-ssh -i '*' state.apply setup
This runs the minimum set of states in a specific order. Be sure to look at salt_ssh/states/setup.sls to comment or uncomment any additional items you do or don't want installed during the setup process.
This takes a while and there aren't any status updates as things progress. Be patient!
sudo salt-ssh -i '*' state.apply state_file
The backup configuration is stored in
Whenever configuration is stored in
Backups are stored in
It has configurations for using AWS S3 and SES. Those configurations can be added to the roster file. You can see an example of this in the roster file.
ElasticSearch State (Debian/Ubuntu Only)
Installs the specified version of elasticsearch found in salt_ssh/pillars/default.sls. The fallback is version 2.3.4. This also installs the openjdk_7_jre dependency.
Installs the lates version of ImageMagick via the package manager for the OS.
Ensures logrotate is installed on the remote system (it most likely is) via the package manager for the OS. Adds a rails config in /etc/logrotate.d.
Ensures monit is installed via the package manager for the OS and running. Makes a backup of the original /etc/monit/monitrc then replaces it with config that monitors any monit configs stored within the rails application.
The monit config file is setup to use AWS SES which you can add the credentials to the roster file.
Ensures MySQL is installed via the package manager for the OS and running. Currently, you will need to create the user account due to the following open issues:
Once resolved, the option to create MySQL users will be re-enabled.
The code is commented out in salt_ssh/states/user.sls if you decide you want to try and use it before the issues are resolved.
Installs NGINX via the package manager for the OS and ensures it is running.
Ensures nodejs is installed via the package manager for the OS and creates a node symlink if it doesn't exist.
Ensures redis is installed via the package manager for the OS and is running.
Installs the following gems under RVM:
creates /var/www if it doesn't exist and sets the owner of that directory to the specified user in the user state.
Installs RVM under the specified user in the user state. Sets the default to the specified version in salt_ssh/pillars/default.sls.
Creates a user that is defined in salt_ssh/pillars/default.sls. If a user is not found it will default to user named deploy. This state also adds the user to /etc/sudoers for executing code without the need for a password.
Update salt_ssh/pillars/default/init.sls to add your ssh key to log in as the user created in the user state. This is required since the user created does not have a default password assigned. This is done for strong security!.
Take a look at the code before you use it to make sure that it works the way you expect or want. After the code is generated you can modify it to fit your needs before executing.
To uninstall salted_rails_server simply delete the following files:
- /salt_ssh #directory
I am looking for constructive criticisim on making this better and easier for everyone who could use it.
- Fork it ( https://github.com/vmcilwain/salted_rails_server/fork )
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create a new Pull Request