From September 4 to 6, in Saint Petersburg, the Selectel conference hall will host a three-day .
We built the program based on the idea that theoretical works on DevOps, just like manuals for tools, can be read by everyone independently. What matters are the experiences and practices: explanations of what should and shouldn't be done, and insights into how we do things.
Every company, every administrator or developer has their own level of DevOps. Some misuse Git, while others implement SRE. The course is organized so that everyone can find something relevant to implement here and now.
We start with Git, then we look at application development, the interaction of code and infrastructure, build CI/CD, describe infrastructure as code (IaC), test the resulting solution, set up monitoring, collect and analyze logs, and finally, we reach SRE: turning reliability into a measurable and manageable story.
Git
Currently, only those who bought their first laptop yesterday do not use Git. It is a trivial and ubiquitous tool, yet we often encounter its misuse: from force pushing to master, to copying files from Git to the server using Ctrl-C, Ctrl-V.
We explain what not to do, what to do, and how it’s done at Southbridge.
Practice session: Git basics, teamwork.
Topic #1: Basics of Working with Git
- Basic commands git init, commit, add, diff, log, status, pull, push
- Git flow, branches and tags, merge strategies
- Working with multiple remote repos
Topic #2: Team Collaboration with Git
- GitHub flow
- Fork, remote, pull request
- Conflicts, releases, revisiting Gitflow and other flows relevant to teams
The material is organized so that administrators and developers can immediately implement all practices in their work.
From the DevOps perspective, proper use of Git streamlines and automates development and administration processes, eliminates a number of recurring issues, and increases productivity.
DevOps Developer
We look at DevOps through the eyes of a developer: launching the local environment, writing an application, setting up its monitoring and logging, testing it locally, organizing the storage of variables/secrets, and service discovery, exploring tracing (opentracing).
Topic #3: Working with the Application from a Development Perspective
- Setting Up a Local Environment: Practical Recommendations
- Building a Microservice with Python (Including Tests)
- Using Docker Compose in Development
Topic #4: Interaction Between Code and Infrastructure
- Working with Configuration Files
As a result, developers will see how the code should send logs, how to test it, and how it will be debugged in the future. Administrators will understand the needs of developers: what errors in the code occur, how to organize testing for developers, and how to test the project themselves.
At this stage, the main task of DevOps is addressed: establishing mutual understanding and collaboration between developers and operations. This is a key step in moving from simply handing off tasks to responsible collaboration.
As a result, the speed and quality of work improve.
CI/CD
Modern automation implies CI/CD. We will start by looking at manual automation: makefiles, git hooks, scripts. We will analyze when these tools are still relevant and when they should not be used.
Then we will look at the best practices of modern CI using GitLab as an example.
Topic #5: CI/CD Introduction to Automation
- Introduction to Automation
- Tools (bash, make, gradle)
- Using Git Hooks for Process Automation
- Factory Pipeline Assembly Lines and Their Application in IT
- Example of Building a 'Common' Pipeline
- Modern Software for CI/CD: Drone CI, BitBucket Pipelines, Travis, etc.
Topic #6: CI/CD: Working with GitLab
- GitLab CI — Overview
- GitLab Runner, Their Types and Applications
- GitLab CI, Configuration Features, Best Practices
- Stages of GitLab CI
- GitLab CI Variables
- Build, Test, Deploy
- Execution Control and Restrictions: only, when
- Working with Artifacts
- Templates Inside .gitlab-ci.yml, Reusing Actions in Different Sections of the Pipeline
- Include — Sections
- Centralized Management of gitlab-ci.yml (One File and Automatic Push to Other Repositories)
Collaboration between Administrators and Developers Reaches a New Level: The Administrator Writes the CI Template, and Developers Edit It, Building Their CI Independently of the Administrator.
Dependency of Developers on Administrators Decreases, Reducing Manual Work, and Eliminating the Problem of the 'One Person Who Knows How to Work with the Makefile'. Deployments Are Reliable and Fast.
IaC
The theme of Infrastructure as Code using Terraform will be presented by Selectel cloud administrator Alexey Stepanenko. He will demonstrate how to quickly and automatically deploy and scale servers, how to package images automatically, and how to use configuration templates to get pre-configured machines right away.
A person who has created thousands of IaC solutions will share the right approaches and what to avoid.
The Selectel cloud solution requires minimal adjustments for Google and Amazon clouds.
Nikolai Mesropyan from Southbridge will demonstrate how to deploy a running application without downtime using Ansible and how to verify its functionality.
If you manually adjust the infrastructure (configuring servers, installing libraries, packages as needed), when trying to create a copy of the environment, you will have to recall and reproduce all your actions. This task can easily take 3-5 days. Working with infrastructure as code ensures that you have an up-to-date description of the environment that can be deployed in minutes.
Nikolai will explain how to write playbooks, common mistakes, and why playbooks may sometimes run slowly or not as expected. This is the result of many years of using IaC at Southbridge.
Topic #7: Infrastructure as Code
- IaC: treating infrastructure as code
- Cloud providers as infrastructure suppliers
- System initialization tools, image building (packer)
- IaC using Terraform
- Configuration storage, collaboration, application automation
- Practice of creating Ansible playbooks
- Idempotency, declarativity
- IaC using Ansible
- Database as Code / High Availability of PostgreSQL
The infrastructure gains declarativity and idempotency.
An administrator learns to manage complex infrastructure: quickly create new environments, maintain consistency across all environments, and track change history, which is critical when multiple teams work on a project.
A developer can explore the infrastructure and deploy environments independently.
The bonus of this section is the creation and configuration of a high-availability PostgreSQL database cluster. We will provide a ready-made playbook used in Southbridge, you will deploy a cluster on a training stand, and you can implement this solution in your company.
Testing infrastructure and monitoring.
Automation allows you to roll out an error to a thousand servers at once. Every change requires testing. On the other hand, manual testing takes so much time that it undermines the advantages of automation.
We will demonstrate how to write role tests in practice. As a result, you will be able to write tests for your company. No more need to remember the settings you've made; just describe them in tests and automatically verify that all previous solutions and workarounds are in place.
Next, we will learn to automatically add all new servers to monitoring. We will separately examine infrastructure and application monitoring, showing both poor and good practices.
Topic #8: Infrastructure Testing
- Testing and Continuous Integration with Molecule and Gitlab CI
- Using Vagrant
Topic #9: Infrastructure Monitoring with Prometheus
- Why Monitoring is Needed
- Types of Monitoring
- Notifications in the Monitoring System
- How to Build a Healthy Monitoring System
- Human-readable Notifications for Everyone
- Health Check: What to Pay Attention To
- Automation Based on Monitoring Data
A malfunctioning monitoring system means there is no monitoring at all. The business doesn't care if the homepage of the online store is accessible if the payment form is returning an error.
In monitoring setup and troubleshooting, developers and administrators participate equally. Traditionally, monitoring tasks fall on administrators. Our course will show developers their role in establishing effective monitoring. Administrators will gain best practices from Southbridge. As a result, the losses caused by failures and slowdowns of the site or application will quickly decrease.
Bonus for the section: automation based on monitoring. For example, monitoring notifies that traffic has hit the site, and the scaling of web servers starts automatically.
Logging
The main mistake in dealing with logs is that administrators and developers view them directly on servers. If you have more than one server, this takes a long time. It’s insecure: developers access servers where they shouldn't be.
DevOps requires centralized collection, processing, and analysis of logs.
Topic #10: Application Logging with ELK
- Main applications and capabilities of Elastic (search, storage, scaling features, customization flexibility)
- Overview of Kibana (main features, query language, dashboard management, graph creation)
- Overview of products based on Elastic and their applications
- Gathering metrics in APM (application tracing)
- Additionally: Overview of the new product — SIEM
Implementing this approach will make logs a simple and understandable tool for analyzing, configuring, and tuning the application and infrastructure.
SRE
And we come to the topic that Southbridge is only beginning to explore, and for which other speakers want to stay for the last day of Slyerma. We are glad that Ivan Kruglov from Booking.com agreed to present it.
The project lives in the real world, where reliability is never absolute, and every decision has a cost.
What is SLA in relation to a complex project? For example, how to assess that the site is available, but images load with a delay. What are the SLA metrics, where to take them from, how to collect them?
How to establish SLA? How to meet them?
Topic #11: SRE
Definition of SLA, SLO, Error Budget and other daunting terms from the world of SRE
SRE: Practice of monitoring SLI and SLO
SRE: Practice of applying Error Budget
SRE: Managing interruptions and operational load (apigateway, service mesh, circuit breakers)
The business wants SRE. At least at a basic level: take a backup server or restore from a backup? One database or a cluster? Implement DDoS protection preventively or only during an attack?
The director will not be satisfied with an explanation that 'the site is working' when a client calls and reports that the order form is not loading.
Therefore, it is essential for a DevOps engineer to at least have a superficial understanding of SRE to adequately discuss business needs.
Summary
During the time administrators and developers will learn:
— how to work correctly with Git;
— how to organize local development;
— how to configure (administrators) and use (developers) CI/CD;
— how to treat infrastructure as code;
— how to test infrastructure;
— how to monitor infrastructure and applications;
— how to configure logging;
— how to understand, and ideally — use SRE.
For attentive readers — with the promo code habrapost, get a 15% discount.
For all aspects, we prepare practice and tools. Thus, every participant returning from Slurm will be able to elevate their company to the next level of DevOps.
For businesses, this means reduced administration and development costs, decreased downtime, increased reliability, faster feature delivery, and bug fixes.
Source: habr.com
