Skip to content

AwareInterface, Graylog2 with Logstash and Contributing to the new PHPUGHH website - PHP UserGroup

link to meetup event.

Where

Jimdo
Stresemannstraße 375
Hamburg

AwareInterface By Stev Leibelt

  • reminder of dependency injection
  • increases the readability of a class structure
  • defined way of inject object/typ
  • interface injection could lead to a project based rule to distinguish between mandatory and optional dependencies
  • slides available hear.

Logstash and Graylog2 by Alexander Bernhardt

Simple log all.

questions to the log

  • what happens on the other server?
  • what happens when and on what circumstance?
  • what are you logging?

how to solve this?

By using Logstash, Redis and ElasicSearch, aggregate all and push all to a graylog2.

  • graylog can do some kind of monitoring, known as streams.
  • you can add a alert method to each stream.
  • nagios can listen to a graylog stream.
  • could not replace statsd or graphite

Talk And Call For PHPUGHH Website By Stephan Vock And Ole Michaelis

  • two Pages for one user group, which one to choose?
  • the usergroup decides to use the new page.
  • you need to have installed jekyll, rake or use the vagrant box
  • directory structure
    • each speaker should pull his own talk below "talks"

How To Contribute

  • fork repository
  • git checkout -b feature/foo
  • do the changes
  • git commit
  • pull request to the main repository
  • github.io builds new page on its own
  • git remote add upstream git@github.com:phpughh/phpughh.github.com
  • git fetch upstream
  • git merge upstream/master
  • git push
  • issues are available
  • enhancement issues is the roadmap
  • open issues if needed
  • links available as ticket
  • take a look to the bephpug (github)

Next Level DevOps And Softwarearchitecture Of A Modern Onlinegame - PHPUserGroup Meetup

Mindworks
Jarrestraße 42A
Hamburg

Next Level DevOps By Ole Michaelis

Preliminary Consideration

  • infrastructure is created by feature (but without clean up or cleaning things up)
  • did a practical training round in admin team for half a year

What Is DevOps?

  • you build it, you run it (until it goes offline)
  • monitor it, automate it, measure/metering it
  • build small tools and services to form an api

How Became A DevOp?

  • extend your development skills
  • learn and do refactoring
  • learn the shell
  • learn the operation system
  • pull deployment with deployment hooks

Softwarearchitecture Of A Modern Onlinegame By Tobias Rojahn

Preliminary Consideration/Requirements

  • crossplattform (mobile and web)
  • realtime game (fast information about status changes)
  • multiplayer (user can influence each other)

Architecture

  • user (request websocket from web server)
  • NodeJS (handles websocket connection to redis and global redis)
  • redis (message queue with push and pull)
  • php worker (long living php process, asks webservices or database, are forkable by using php forking mechanism)
  • if something is calculated by the php worker, the message is pushed in the global redis

The PHP Worker

  • long living workers
  • worker is observing the queue (and event handling) and is pushing the message to the dispatcher
  • each message has a type to push to the right controller
  • dispatcher is using the right controller (with a bunch of internal to external mapping and nearly zero logic)
  • controller is pushing the message to the right domain service (using the right domain objects and/or repositories)
  • controller is working with multiple db views
  • domain service can also call the event dispatcher to trigger other systems (not core systems)

Deamon

  • only creates messages
  • just time controlled game events

Cronjob

  • only creates messages

NodeJS

  • socket (via socket io) replaces session
  • add additional data (with indexes to gain speed) to the socket (via message queues from php)
  • node to php: send all data
  • php to node: a combination of data to all connected sockets
  • forwarding of fitting messages (with removing of internal datas)

Testing

  • API-Tests
    • description
    • ingoing message (test data)
    • outgoing message (expectations)
  • based on fitrues
  • only php layer
  • rollback on each test

FrOSCon - Database DevOps With Flyway, Git, Maven, MySQL And Jenkins

By Michael Hüttermann.
Thanks for the book again, i will try to write a review about it this year :-).

What Is This Talk About

  • what is a DevOp
  • the goal
  • the problem
  • the solution
  • recipes and pitfalls
  • examples - not in this documentation
  • demo (MySQL, Flyway, Jenkins, Git, Maven, Gradle, Sonar, Vagrant) - not in this documentation

How Is Part Of The Team

  • everybody how is envolved in the process of creating the software

What Is Not A DevOp

  • is already a buzz word
  • it is not a new project role
  • its also not a new tool-suite
  • devOps is not a new department / business unit
  • *

What Is A DevOp

  • development and operations
  • better communication
  • improved collaboration

The Goal

  • shared incentives
  • holistic metrics
  • common processes (like kanban)
  • shared tools (same deployment tools for development and production for example)
  • high automation degree
  • improve and accelerate delivery - downsize the batch size
    • small releases
    • downsize the changesize to keep up the frequency
    • improve the cycle time (from bug finding/feature request to release the patch/feature)

The Problem

  • a lot of completed functions/features facing a slow release cycle
    • release small, release often
  • problem between development (want feature online) against operation (want stable and "relaiable" software)

The Solution

  • value stream map
  • continuous integration
  • continuous delivery (each commit moves system into stable and releaseable version)
  • continuous deployment
  • development and operation is merged together to create a infinie loop of release and feedback (both directions)
  • share knowledge and experience

Define clearly what is a release (new feature, bugfix, and so one). Again DevOps is not a new layer between the two areas. Responsibilites is still clear to reproduce scenarios (automate as much). It is about people, not about tools. Implement culture of communication. Try to find conceptual deficits (also software design problems) as early as possible. Add a version number to your database layout (most likly same release number than code) - flyway, liquibase, self-made

The Area Matrix

  • area 1 - extend development to operations
    • practice
      • use tools like puppet/chef/cfengine to provision environments from versioned code
    • goal
      • fast feedback through automations
      • reuse of code and tools
      • reliability of delivery process and provisioning
  • area 2 - extend operations to development
    • practice
      • provide monitoring and log files to development (or automated database snapshots to reproduce bug on development machine)
    • goal
      • share information about state in production
      • enable development to improve
      • enable development to trace production incidents
  • area 3 - embed development into operations (end user experience is goal to reach)
    • practice
      • set stability and capacity as development goals
    • goal
      • align goals, share incentives
  • area 4 - embed operations into development
    • practice
      • operations gives feedback about the design of the application that is under development, early and often
    • goal
      • avoid not releaseable design

Recipes And Pitfalls

  • automate to ensure repeatability and foster collaboration (build once on a build server and release)
  • consider kanban (scrum is more for development but bad for organisation)
  • consider thorough change and config management - content management
  • track to ensure traceability (which build/release contains which tickets/bugs - artifactory)
  • monitor to support accountability (nagios and everything)
  • dashboard what you are doing (talk to each other what you are doing or what you have done)
  • use version control to ensure reproducibility (no manual tweaking after checkout)
  • consider pipelines/process from "put in feature/bugfix to release"
  • create (executable) documentation to, well, document (try to define goals and what it needs to reach it)
  • align goals and incentives of devs and ops (small cycle time)
  • ask and help, open culture of communication
  • respect your colleagues (stability against features, both leads to great user experience)