How to successfully migrate to DevOps .pdf

v
Следете актуалните обяви за DevOps
Marian Marinov
How to successfully migrate to DevOps
mm@yuhu.biz

v
Disclaimer 1!
➢ For me DevOps is the new sysadmin...
➢ But with more responsibilities!
➢ I'm sharing my personal point of
view and my personal mistakes.

v
Disclaimer 2!
➢ This is not a HashiCorp presentation :)
➢ Its just simpler then presenting the
same thing with k8s

v
Is DevOps right for me?
➢ How big is my team?

v
➢ What do I have at the moment:

v
➢ how many servers?

v
➢ how many applications?

v
➢ how many applications?
➢ how many data sources(SQL, NoSQL, FS Storage)

v
Dev: git push github master
Sys: ssh server
apt-get install git apach2 mysql php-common php7.4-common php7.4-mysql
php7.4-cgi php7.4-fpm iptables iptables-persistent
cd /home/app/
git clone github/repo
git checkout master
echo -e '$db_user=”app1”;n$db_pass=”secret”;' > app-config.php
vi /etc/apache2/conf.d/app.conf
vi /etc/php/7.4/fpm/pool.d/www.conf
systemctl start apache2
systemctl start php7.4-fpm.service
systemctl start mysql
mysql -e 'CREATE DATABASE app1'
mysql -e "GRANT USAGE *.* app1@localhost IDENTIFIED BY 'secret'"
mysql -e 'GRANT ALL ON app1.* TO app1@localhost'
# setup the firewall
The OLD WAY

v
Dev: git push github master
Ops:
1. Install terraform
2. Write the TF configuration for terraform
3. Configure your infrastructure with terraform
4. Deploy Nomad with Terraform
5. Write the Nomad configuration for the VMs/Containers and the
deployment of your app
6. Write a bash scripts that will:
6.1. Deploy your app
6.2. Deploy your DB and setup user
6.3. Deploy your web server setup
The NEW WAY

v
Pros:
OLD
- simpler
- faster
- requires knowledge only for the service(s)
Comparing the OLD vs. NEW ways

v
Pros:
OLD
- simpler
- faster
- requires knowledge only for the service(s)
NEW
- repeatable/reproducible
- scalable
- requires less scripting
- removes the requirement to know the actual service(s)

v
Conns:
OLD
- requires understanding of the service configuration
- requires bash scripting

v
Conns:
OLD
- requires understanding of the service configuration
- requires bash scripting
NEW
- requires a lot of knowledge for high level software
(terraform, nomad, ansible etc.)
- takes longer time to deliver initial setup
- removes the requirements to know the actual services
-

v
Dive into the DevOps way

v
* Installing teraform
+ typical learning time 1-2 weeks
* Installing Nomad
+ with terraform, around a day
+ without terrafrom 2-3 days
* Choosing the infrastructure configuration
+ decide will we use VMs(KVM, Xen, Hyper-V, AWS, GCP, Azure, Alibaba) or
containers(Docker, LXD, runc)
+ decide how you will split the infra
- will we have web loadbalancers/proxies
- will we keep the DB on the same node as the web application
- will we have a replication for the DB
- will we have a separate node for the firewall
- result should be documented infrastructure and sometimes even a graph
depicting the connection between the nodes
* Decide if you are going to use a secret management system like Vault
* Prepare the deployment configuration
* Test the deployment configuration
* Sometimes... add CI/CD for the application

v
When to choose DevOps
over Sysadmin

v
➢ You are expecting rapid growth
➢ You are expecting to setup this infrastructure often
➢ You are expecting to reprovision this application often
➢ You need to implement complex CI/CD

v
Team considerations

v
➢ For DevOps teams of less then 5
➢ if only 2 or 3 people know the tools
➢ if the whole team knows the tools
➢ try to do a deployment with these tools at least 4
times a year and rotate the people doing these test
deployments

v
➢ For DevOps teams of more then 5
➢ make sure you have at least 4 persons that
know the tooling
➢ make sure your setup and infrastructure
configuration are well documented
➢ make sure you test frequently your deployments
➢ keep your infrastructure code in a separate repo

v
Documentation considerations

v
➢ Include links to specific topics from the
upstream documentation
➢ Provide specifics for your own environment
➢ If possible keep these comments within the
infrastructure configuration files, not separate

v
Technical considerations

v
➢ Scaling is not an automatic process, until you make it
➢ DBs don't scale easy horizontally
➢ replication is mandatory
➢ sharding is preferable, but also not easy
➢ read/write split is needed, but also not easy
➢ LB/Proxies add latency
➢ failure tolerance
➢ Session storage need to scale and be accessible to
all web nodes
➢ Communication between everything is now over TCP,
instead of Unix sockets

v
ABSTRACTION
ABSTRACTION
the devil is in the details

v
➢ Ansible
➢ just to configure the apache, php and mysql
➢ Terraform
➢ to be able to deploy on different clouds
➢ Nomad
➢ to be able to control the scale

v
➢ Ansible
➢ ready made examples
➢ limited functionality
➢ reducing your ability to provide specific configuration
➢ A lot of times resulting in DevOps needing to go around it
and just execute some commands

v
➢ Terraform
➢ can do what Ansible can, but it is not built for that :)
➢ abstracts Ansible and makes it harder to understand what
the end result would be
➢ declares the desired end result, not how to reach it
➢ almost entirely removes the resulting configuration from
the equation
➢ problems with terraform configuration may cause delays in
delivering a fixes to the live system

v
➢ Nomad
➢ requests a VM/container of a certain type
➢ the type is not defined within Nomad, other tools are used for that
➢ monitors the VMs/containers to decide if you need more or if
some resource needs to be restarted

v
Hiring
Hiring

v
➢ Candidates focus on the new tech
➢ Forgetting what these tools were build to manage
➢ Not understanding the services (hammer and nail issues)
➢ Learning the basics of system administration is harder
➢ If the provider does not support it, the candidate
does not know it exists/it is possible

v
Marian Marinov
Questions?
mm@yuhu.biz

v
Marian Marinov
mm@yuhu.biz
Contacts:
https://www.linkedin.com/in/mariandmarinov/
https://github.com/hackman
Thank
you!

How to successfully migrate to DevOps .pdf

More Related Content

Similar to How to successfully migrate to DevOps .pdf (20)

More from Marian Marinov (20)

Recently uploaded (20)

How to successfully migrate to DevOps .pdf