Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 46 Next »

Process documentation

What version of fedora is running?

it's in the footer of the main page

for example http://localhost:8080/fedora/

What version of the app is deployed?

$ cat /opt/sufia-project/current/REVISION 

Deploy the application with Capistrano

  • cd into the root dir of your chf-sufia repository

$ bundle exec cap [staging|production] deploy

  • If this is the first deploy, you need to start web services (because before this there was no project and apache / tomcat would fail to find various directories and config files). ssh to the ec2 machine as the sudo (ubuntu) user.

$ sudo service tomcat7 restart

$ sudo service apache2 restart

Addt'l useful capistrano info

 

Deploy with downtime

bundle exec cap staging maintenance:enable REASON="a test of maintenance mode" UNTIL="12pm Eastern Time"
  • Deploy as usual / desired
  • Do anything else needed on the server that required the downtime
bundle exec cap staging maintenance:disable

 

Building a new machine on AWS with Ansible

  1. (Note: ansible-vault password and all current AWS keys are in shared network drive)
  2. Generate a new ssh key on AWS (EC2 > Keypairs)
    1. place it in ~/.ssh
    2. chmod 0600.
    1. useful command if you're having problems with the key: $ openssl rsa -in chf_prod.pem -check
  3. Check ansible variables
    1. $ ansible-vault edit group_vars/all
    2. Look for # Use these temporarily for new instances
    3. ensure your ssh key is listed under keys_to_add
  4. run the ansible playbook
    1. $ ansible-playbook -i hosts create_ec2.yml --private-key=/path/to/your/.ssh/key.pem --ask-vault-pass
    2. OR, if you're re-running scripts on an existing machine: 
      1. $ ansible-playbook -i hosts my_playbook.yml --ask-vault-pass [-e hosts=ec2hosts]
    3. note that if there's a failure during postgres setup handlers may not run – watch out for this. if this happens it's potentially best to start over completely.
  5. Assign an elastic IP to the new box
  6. Ask IT to give you a DNS entry for the elastic IP if desired
  7. Consider naming the aws volumes for 'root' and 'data' – this isn't done in the scripts (but probably could be!)
  8. Set up to use capistrano (below) or just deploy with capistrano (above)

Set up Capistrano (first-time use)

Create an entry for the deploy user in your .ssh/config:

Host staging
 Hostname NEW.IP
 User hydep
 #IdentityFile ~/.ssh/your_key
 ForwardAgent yes
  • This keeps us from publishing server names, etc, in the cap config files which live in our public repo.
  • don't change the Host designation without:
    • Changing it in capistrano, e.g. deploy/staging.rb, to match
    • Clearing it with everyone who might deploy (they'll have to change their ssh config as well.
  • this will use your personal ssh key – the one that matches your public key on github, which is added to the deploy user by ansible scripts.

 

Git repositories for ansible - structure and use

Code lives at https://github.com/curationexperts/ansible-hydra

Wrapper with local configuration lives at https://bitbucket.org/ChemicalHeritageFoundation/ansible-inventory. Wrapper contains:

  • our hosts file
  • our group_vars files
  • ansible-hydra as a git submodule
  • an ansible.config which points to ansible-hydra for roles_path.

  • Aside: pull requests can be submitted via branches; there's really no need to fork this repo since we'll all be owners.

To use

  • $ git clone clone git@bitbucket.org:ChemicalHeritageFoundation/ansible-inventory.git
  • $ cd ansible-inventory
  • $ git submodule update --init

Subsequently, when you pull ansible-inventory and the submodule has been updated, just run

  • $ git submodule update

 

  • No labels