Web-Anwendungen in der Cloud

klassisches Hosting | Merkmale

Verantwortung für Server liegt beim Hoster
- Security - Patches
- Absicherung der Infrastruktur
Entwickler haben nur begrenzte Möglichkeiten
Setup ist einzigartig
zusätzliche Server können u. U. nicht immer zeitnah zur Verfügung gestellt werden
Festlegung auf eine Architektur
- Umbau / Migration schwierig
dynamisches Scaling nicht möglich

Hosting in der Cloud | Merkmale

Verantwortung für Server liegt bei der Agentur / Entwickler
- Security - Patches
- Absicherung der Infrastruktur
Entwickler haben alle Möglichkeiten / Pflichten
Setup ist austauschbar
zusätzliche Server können meistens zeitnah zur Verfügung gestellt werden
Festlegung auf eine Architektur nicht notwendig
- Umbau / Migration einfacher
dynamisches Scaling wird unterstützt
ermöglicht "immutable Infrastructure"

Immutable Infrastructure

Server wird nach seiner Erstellung nicht mehr verändert
verhindert Bildung von "Snowflakes Servern"
verhindert manuelle Konfigurations-Fehler
der Server hat einen definierten Zustand nach jedem Deployment
- sowohl manuell als auch automatisch testbar
Konfiguration des Servers muss schnell gehen
große Teile der Applikation sollten bereits im Server-Image enthalten sein
bei einem Release wird der komplette Server ausgetauscht
meist im laufendem Betrieb möglich

Tools für Shopware in der Cloud

Terraform

Definition von Infrastruktur als Code
Kommunikation über die AWS-Api
Status des Setups wird gespeichert (state-file / remote-state
es können Variablen definiert werden
Terraform-Code kann in Modulen organisiert werden
Infrastruktur kann in Versionsverwaltung organisiert werden

Terraform

# Create a new instance of the latest Ubuntu 14.04 on an
# t2.micro node with an AWS Tag naming it "HelloWorld"
provider "aws" {
  region = "us-west-2"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami           = "${data.aws_ami.ubuntu.id}"
  instance_type = "t2.micro"

  tags {
    Name = "HelloWorld"
  }
}
»

Ansible

Definition von Konfiguration
Kann lokal und remote ausgeführt werden
definierter Konfigurations-Zustand kann (wieder) hergestellt werden
es können Variablen definiert werden
Ansible-Code kann in Rollen ausgelagert werden
Konfiguration von Servern und Applikationen können in Versionsverwaltung organisiert werden

Ansible

---
# These tasks install http and the php modules.

- name: Install http and php etc
  yum: name={{ item }} state=present
  with_items:
   - httpd
   - php
   - php-mysql
   - git
   - libsemanage-python
   - libselinux-python

- name: insert iptables rule for httpd
  lineinfile:
    dest: "/etc/sysconfig/iptables"
    create: yes
    state: present
    regexp: "{{ httpd_port }}"
    insertafter: "^:OUTPUT "
    line: "-A INPUT -p tcp  --dport {{ httpd_port }} -j  ACCEPT"
  notify: restart iptables

- name: http service state
  service: 
    name: httpd
    state: started
    enabled: yes

Packer

Beschreibung eines Server-Images
Kann mit Hilfe unterschiedlicher Builder / Provisioner individuelle Server-Images erstellen
aws-builder ermöglicht Erstellung eines AMI
Es können beliebige Skripte in den Prozess eingebunden werden
kann automatisiert ausgeführt werden

Packer

"builders": [
    {
      "type": "amazon-ebs",
      "profile": "your-aws-profile",
      "region": "eu-central-1",
      "source_ami": "ami-e9c01086",
      "instance_type": "t2.micro",
      "ssh_username": "ubuntu",
      "ami_name": "application-name-appserver-{{timestamp}}",
      "ssh_keypair_name": "name-of-insecure_packer_key",
      "ssh_private_key_file": "insecure_packer_key",
      "tags": {
        "Name": "application-name-appserver-image-stage"
      },
      "ami_description": "image for appserver of your application"
    }
],
"provisioners": [
    {
      "type": "shell",
      "execute_command": "echo 'vagrant' | {{ .Vars }} sudo -E -S sh '{{ .Path }}'",
      "inline": [
        "sleep 30",
        "export DEBIAN_FRONTEND=noninteractive",
        "apt-get install software-properties-common python-software-properties --assume-yes",
        "apt-add-repository ppa:ansible/ansible",
        "/usr/bin/apt-get update",
        "/usr/bin/apt-get upgrade --assume-yes",
        "/usr/bin/apt-get -y install ansible"
      ]
    },
]

inspec

Tests für Infrastruktur
geschrieben in einer Ruby-DSL
Ruby kann verwendet werden
Tests konnten in Packer-Prozess integriert werden
funktionale Tests während Image-Erstellung möglich
es können Test-Profile erstellt werden

inspec

require "yaml"
path_to_config = File.dirname(__FILE__)  + '/../files/your_config_file.yml'
shop = YAML.load_file(path_to_config)

control "application root directory" do
  impact 0.8
  title "Test permissions of the root folder of the shop"
  describe directory('/var/www/your-application') do
    its('mode') { should cmp '0774' }
    its('owner') { should cmp 'www-data' }
    its('group') { should cmp 'www-data' }
  end
end

control "application installation" do
  impact 0.8
  title "Test the correct installation of the shop"
  describe file(application['application_docroot'] + "/path/to/some/known/file/after/installation") do
    it { should exist }
  end

  describe file(application['application_docroot'] + "/config.php") do
    it { should exist }

    its('content') { should include "'host' => '" + application['db_host'] + "'" }
    its('content') { should include "'port' => '" + application['db_port'] + "'" }
    its('content') { should include "'username' => '" + application['db_user'] + "'" }
    its('content') { should include "'dbname' => '" + application['db_name'] + "'" }
  end
end

Unser Setup