Drupal cambs ansible for drupal april 2015
•Als PPTX, PDF herunterladen•
0 gefällt mir•424 views
General introduction to Ansible for managing Drupal sites and servers. April 2015.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Drupal cambs ansible for drupal april 2015
Ähnlich wie Drupal cambs ansible for drupal april 2015 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Drupal cambs ansible for drupal april 2015
- 1. Ansible for Drupal Or, “Running your Drupal development operation like a farm”
- 2. What is Ansible ◦ Open source (naturally) ◦ Simple ◦ Agentless ◦ Powerful ◦ Not on Windows. Sorry!
- 3. Benefits of Ansible ◦ Secure ◦ Repeatable ◦ Fast ◦ Idempotent
- 5. “ Servers are livestock, not pets.
- 6. “ Play it again, Sam
- 7. “ In a galaxy far, far away… there’s a role for that https://galaxy.ansible.com/
- 8. “ Read it like an open book
- 9. “ Please do not feed the sheep
- 10. Installation Only on local machine Use Linux package managers or pip on Macs Requirements: ◦ Python 2.6 or greater
- 11. Ansible Components ◦ Hosts ◦ Playbooks ▫ Roles Tasks Vars Templates Handlers
- 12. Key Ansible Modules ◦ Apt/Yum - install stuff ◦ File - change file settings ◦ Command - run shell command ◦ Synchronize - rsync ◦ Service - control services
- 13. Basics: your first Ansible command Inventory file (hosts): [webservers] example1@miniserver.com example2@miniserver.com Command: $ ansible -i hosts webservers -m ping Output: example1@miniserver.com | success >> { "changed": false, "ping": "pong" } example2@miniserver.com | success >> { "changed": false, "ping": "pong" }
- 14. Our Drupal clone setup role - tasks file - name: Git Clone to Location git: repo=https://{{gituser}}:{{gitpass}}@{{reponame}} dest={{location}} - name: Copy settings command: cp {{location}}/sites/default/default.settings.php {{location}}/sites/default/settings.php - name: Set permissions of settings file: path={{location}}/sites/default/settings.php mode=0777 - name: Set Permissions of folder file: path={{location}}/sites/default mode=0777 - name: Create Drupal command: drush -r {{location}} si standard --db-url='mysql://{{dbuser}}:{{dbpass}}@localhost/{{dbname}}' --site- name=Spawn --account-name={{username}} --account-pass={{dbpass}} -y
- 15. Our Drupal clone setup role - output $ ansible-playbook -i hosts drupal-git-clone.yml --extra-vars "target=example.willhallonline.net" PLAY [example.willhallonline.net] ************************************************ GATHERING FACTS *************************************************************** ok: [example.willhallonline.net] TASK: [willhallonline.drupal-clone-setup | Git Clone to Location] ************* changed: [example.willhallonline.net] TASK: [willhallonline.drupal-clone-setup | Copy settings] ********************* changed: [example.willhallonline.net] TASK: [willhallonline.drupal-clone-setup | Set permissions of settings] ******* changed: [example.willhallonline.net] TASK: [willhallonline.drupal-clone-setup | Set Permissions of folder] ********* changed: [example.willhallonline.net] TASK: [willhallonline.drupal-clone-setup | Create Drupal] ********************* changed: [example.willhallonline.net] PLAY RECAP ******************************************************************** example.willhallonline.net : ok=6 changed=5 unreachable=0 failed=0
- 16. Intensive Drupal Farming ◦ VLAD (Vagrant LAMP Ansible Drupal) ▫ github.com/hashbangcode/vlad ◦ Ansible with Drush Aliases ◦ Ansible with Docker ◦ Ansible Tower GUI and management system
- 17. Resources http://docs.ansible.com/ http://www.ansible.com/resources http://galaxy.ansible.com/ Shameless plug: http://www.willhallonline.co.uk/blog for more things we’ve been doing with Ansible, amongst other topics.
Hinweis der Redaktion
- First heard about Ansible at Drupal Camp Brighton in January. It’s an IT Automation tool, a bit like Chef or Puppet, but with a couple of key differences which I’ll get explain later. We now use it to do as much as possible. We think it’s really quite brilliant and also relatively easy to pick up. This talk is just aimed at giving you an introduction to Ansible and how it might be used to manage servers running Drupal sites.
- This is really good if you know very little about Systems Administration. Agentless, unlike Chef or Puppet. Uses Open SSH for server access. You’ll likely need to be well acquainted with SSH keys. I haven’t actually been able to find anything you can’t do with it yet. In some cases you wouldn’t want to, because it’s a one off task or you can do it more easily with a bash script. But you could do almost anything with Ansible if you wanted to. It can securely access sudo as well with the right configuration. Can administer Windows servers in conjunction with PowerShell. Can’t be used for the control machine.
- Make new servers secure in double-quick time. Servers can be identical, and therefore reliable. Servers can be ready to go in 10 minutes. Sites can be cloned in another 10. Idempotence means changes are only made when changes are required, for the most part.
- Key principles of using Ansible
- A wise man who knew lots about Ansible said that. They should be there to do a job for you, not for you to look after them. If they’re not working, put them down and use another one. Even if they are working, you might want to move servers for any number of reasons. No problem. Sell that animal off for a tidy profit, and get a new one to feed up. With Ansible, you don’t need to try and nurse poorly servers back to health. They become very disposable.
- Ideally, if you’ve written a process in Ansible, you should be able to run it again immediately after running it the first time and, on the second go, nothing should change. Because it’s idempotent, it should be safe.
- Much like there’s a module for that in Drupal, for Ansible there are roles. Many user contributed roles are stored on Ansible Galaxy and you can download them and include them in your own Ansible projects. You have to be a bit careful at the moment though because Ansible doesn’t have Drupal’s user base and the community provided roles haven’t gone through quite the same level of peer review, and sometimes they have bits of bespoke configuration floating around in them. However, we’ve made use of several really good ones for doing things like setting up nginx and mysql, installing various packages etc. It’s only going to get better.
- By its very nature, Ansible is task driven. Also, it’s written in very human friendly YAML. Consequently, you shouldn’t need to add extra comments to explain what a role, playbook or task does. If you do, you probably need to separate things out a bit more. You’ll see what I mean later when I run through some examples.
- So we know servers are livestock, right. Probably, you want them to be like sheep, in that there aren’t any individuals. What you don’t want is some stranger coming round to pet your very cute sheep and feeding them half a packet of crisps. What I’m trying to say with this rather stretched analogy is that, in an ideal Ansible universe, you wouldn’t need to log in to your servers. At all. Everything could be done remotely. I’d be lying if I said that we didn’t still have to log in to our servers on a regular basis for any number of reasons. But once you’ve logged into a server and made changes, suddenly that server becomes a pet, because you’ve singled it out for special attention. It’s now your prize sheep, and you’ve got to make sure it’s in tip-top condition for the county fair next week. And if it suddenly falls ill, that causes you a problem, because you’ve invested time in it. And we don’t want that to happen.
- You run your farm from your farmhouse in the middle of your plot. You don’t have shepherds or cow-herds out watching your flocks all of the time. No need to install Ansible on servers.
- You keep track of all of your animals in an inventory, which we usually name ‘hosts’. Playbooks contain the details of everything you need to do to keep your animals alive and safe. Explain toles, tasks, etc.
- Ansible modules are more the basic building blocks of tasks. Roles are more like Drupal modules.
- You can arrange them into groups, which is useful if, for example, you’re running some on Debian and some on CentOS. Example of an ad-hoc command. You probably won’t run many of them as playbooks are far more useful. You get nice color coded feedback showing exactly what tasks have been run and what’s changed (if anything). It also usually gives pretty useful error codes which is handy for debugging and the like.
- This role clones a site from its git repository to the site location and creates a Drupal site install. All of the variables are contained in another file, passwords can be stored encrypted using Ansible Vault. We have another role that copies over the database and the files, and then locks down the permissions.
- Here’s the output I got when I ran it as part of a playbook using the command ‘ansible-playbook’ Again, you can see there’s nice colour-coded output, with each task’s outcome recorded. You can use -v for more verbose feedback. No red failed ones, so that’s good. And here’s spawn
- VLAD is a really interesting project by Philip Norton and Dan Bohea which enables you to fire up a Drupal development environment on a local virtual machine. It looks awesome and we’ll be looking at this in the near future. Drush aliases, as I’m sure a lot of you know, are very useful for a great number of things, including syncing databases and files between production and development environments, performing upgrades to Drupal etc. Some of our Ansible playbooks incorporate Drush alias commands. Serious power.
- Some useful resources