Changeset - 4acb74ace813
[Not reviewed]
0 1 0
Branko Majic (branko) - 8 years ago 2015-10-25 18:28:38
branko@majic.rs
MAR-18: Adding usage instructions for bootstrap and common server configuration.
1 file changed with 117 insertions and 0 deletions:
0 comments (0 inline, 0 general)
docs/usage.rst
Show inline comments
 
@@ -274,3 +274,120 @@ with Python's built-in HTTP server::
 

	
 
  cd ~/mysite/preseed_files/
 
  python -m SimpleHTTPServer 8000
 

	
 

	
 
Bootstrapping servers for Ansible set-up
 
----------------------------------------
 

	
 
In order to effectively use Ansible, a small initial bootstrap always has to be
 
done for managed servers. This mainly involves set-up of Ansible users on the
 
destination machine, and distributing the SSH public keys for authroisation.
 

	
 
When you use the preseed configuration files to deploy a server, you get the
 
benefit of having the authorized_keys set-up for the root operating system,
 
making it easier to bootstrap the machines subsequently via Ansible.
 

	
 
Let's bootstrap our two machines now:
 

	
 
1. For start, create a dedicated playbook for the bootstrap process.
 

	
 
   :file:`~/mysite/playbooks/bootstrap.yml`::
 

	
 
      ---
 

	
 
      - hosts: [communications, web]
 
        remote_user: root
 
        roles:
 
          - bootstrap
 

	
 
2. The ``bootstrap`` role actually has only one parameter - for specifying the
 
   SSH key to deploy to authorized_keys file for the Ansible user on managed
 
   server. This defaults to content of local file ``~/.ssh/id_rsa.pub``, so no
 
   need to make any changes so far.
 

	
 
3. SSH into both machines at least once from the Ansible server in order to
 
   store the SSH fingerprints into known hosts file::
 

	
 
     ssh root@comms.example.com date
 
     ssh root@www.example.com date
 

	
 
4. Now, simply run the bootstrap role against the two servers::
 

	
 
     ansible-playbook playbooks/bootstrap.yml
 

	
 
6. At this point you won't be able to ssh into the machines with root account
 
   anymore. You would be able to ssh into the machine via public key using the
 
   ``ansible`` user. The ``ansible`` user will also be granted password-less
 
   sudo privileges.
 

	
 
7. After this you can finally move on to configuring what you really want -
 
   common configuration and services for your site.
 

	
 

	
 
Common server configuration
 
---------------------------
 

	
 
Each server needs to share some common configuration in order to be functioning
 
properly. This includes set-up of some shared accounts, perhaps some hardening
 
etc.
 

	
 
Let's take care of this common configuration right away:
 

	
 
1. Create playbook for the communications server:
 

	
 
   :file:`~/mysite/playbooks/communications.yml`::
 

	
 
      ---
 
      - hosts: communications
 
        remote_user: ansible
 
        sudo: yes
 
        roles:
 
          - common
 

	
 
2. Create playbook for the web server:
 

	
 
   :file:`~/mysite/playbooks/web.yml`::
 

	
 
      ---
 
      - hosts: web
 
        remote_user: ansible
 
        sudo: yes
 
        roles:
 
          - common
 

	
 
3. Create the global site playbook:
 

	
 
   :file:`~/mysite/playbooks/site.yml`::
 

	
 
      ---
 
      - include: preseed.yml
 
      - include: communications.yml
 
      - include: web.yml
 

	
 
4. Time to create configuration for the role. Since this role is supposed to
 
   set-up a common base, we'll set-up the variables file that applies to all
 
   roles:
 

	
 
   :file:`~/mysite/group_vars/all.yml`::
 

	
 
      ---
 

	
 
      os_users:
 
        - name: admin
 
          uid: 1000
 
          additional_groups:
 
            - sudo
 
          authorized_keys:
 
            - "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
 
          password: "{{ 'admin' | password_hash('sha512') }}"
 

	
 
      common_packages:
 
        - emacs24-nox
 

	
 
5. That's all for configuration, time to apply the changes::
 

	
 
     ansible-playbook playbooks/site.yml
 

	
 
6. After this you should be able to ssh using the user ``admin`` via public
 
   key. The ``admin`` user's password has also been set to ``admin``, and the
 
   user will be member of ``sudo`` group.
0 comments (0 inline, 0 general)