Long life to vagrant… Vagrant is dead

LONG LIFE TO VAGRANT…
VAGRANT IS DEAD
federico.panini@fazland.com - CTO
Development boxes and modern software
lifecycle development techniques.
How our development
team grew up and how we evolved
our development stack.

Federico Panini
CTO @Fazland.com
Team Manager of 8 people
PHP Developer with lots of
years of experience ….
Ops @Fazland.com

Maya
CHO @Fazland.com
Chief Happiness Ofﬁcier
Spreading love all over the
company :)

Fazland is a marketplace where customers
ﬁnd the right professional for all their daily
projects and smart professionals ﬁnd new
clients, while promoting quality, merit and
transparency

How many of you use Vagrant ?

How many of you don’t use Vagrant ?

Martin Fawler
“…This kind of delivery thinking has long been a forgotten corner
of software development, falling into a hole between developers
and operations teams. So it’s no surprise that the techniques in this
book rest upon bringing these teams together—a harbinger of the
nascent but growing DevOps movement.”
Foreword by Martin Fawler in  
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.  
by David Farley; Jez Humble

Continuous Integration:
Improving Software Quality and
Reducing Risk.
by Andrew Glover , Steve
Matyas , Paul M. Duvall
Publisher: Addison-Wesley
Professional Published: June
2007

Continuous Delivery: Reliable
Software Releases through
Build, Test, and Deployment
Automation. 
 
by David Farley; Jez Humble 
 
Published by Addison-Wesley
Professional, 2010

What is this talk about
Development Workstations

Federico Panini

Development Workstations
https://raygun.com/blog/developer-workstations/
https://nickcraver.com/desktop-build/
(StackOverﬂow)

Development TEAMS
Operation TEAMS

REALLY ?!?!?
Software Development Lifecycle

Software Development Lifecycle

Our Experience with Vagrant

Ranting against Vagrant
What is not this talk about

Vagrant conﬁguration

Vagrant provisioning

Docker, LXC, Ansible

let’s Begin!

Virtual Machines

Virtual Machines
Type 1 hypervisor: hypervisors run directly on the system
hardware. A “bare metal” embedded hypervisor
Type 2 hypervisor: hypervisors run on a host operating system
that provides virtualisation services, such as I/O device support
and memory management.

Vagrant is responsible for managing and build efﬁciently Virtual
Machines from the CLI. This is has been for years the most used tools
for DEVELOPERS to create consistent development environments.
What is Vagrant ?

Dependencies and Configuration Isolation
What is Vagrant ? (DEVS PofV)
All the dependencies and all the configurations files are
isolated from the host OS.

Single Disposable Environment
VM’s are managed in a single place by a single scripting ﬁle

Consistent Environment
The guest environment could be recreated with ease by a bunch of
scripting ﬁles

Testing Management Infrastructure
Scripts of your Consistent Workflows
What is Vagrant ? (OPS PofV)
You could test your infrastructure script with a solid, efficient
environment, you can tests your chef or puppet scripts. You can also
tests the same stuff on the cloud, AWS or other providers, which have
the same workflow.

VAGRANT
Recap #1

Recap #1
Vm’s and Vagrant

FAZLAND … the story so far
Fazland was born 6 years ago.
I joined Fazland 5 years ago.
F
A
Z
L
A
N
D
2
0
1
3

No source control repo
source ﬁles managed in a folder backed up with ZIP ﬁles
F
A
Z
L
A
N
D
2
0
1
3

No development environment
the very ﬁrst source ﬁles were from another developer
F
A
Z
L
A
N
D
2
0
1
3

1 developer, 1 CTO, 1 ops, 1 ….
just me!
F
A
Z
L
A
N
D
2
0
1
3
no need to change this stack….

wrong
A little bit of history

how to manage source files ?
how to manage development environment ?
what about server configuration ?
what about application library dependencies ?
how can I remember all the configurations lost ?
what about if my development MAC will crash ?
what about the time and cost of restoring all the environment ?
F
A
Z
L
A
N
D
2
0
1
3

what about if my development MAC will
crash ?
F
A
Z
L
A
N
D
2
0
1
3

immediately I implemented git as source control and a
virtual machine based on VirtualBox
F
A
Z
L
A
N
D
2
0
1
3

I started managing source code consistently.
I started managing development environment consistently and
isolated…. A black box with all the “secrets” about conﬁguration
& co. hidden to the developer. A solid env with clear
dependencies and conﬁguration.
F
A
Z
L
A
N
D
2
0
1
3

F
A
Z
L
A
N
D
2
0
1
3

F
A
Z
L
A
N
D
2
0
1
3
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
# All Vagrant configuration is done here. The most common configuration
# options are documented and commented below. For a complete reference,
# please see the online documentation at vagrantup.com.
config.vm.box = “ubuntu/precise64"
config.vm.box_url = "http://files.vagrantup.com/precise64.box"
config.vm.network :forwarded_port, guest: 80, host: 8383
config.vm.network :private_network, ip: "192.168.0.10"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "1024"]
end
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppet/manifests"
end
end

application in 2013 — Monolith development stack and application
F
A
Z
L
A
N
D
2
0
1
3

F
A
Z
L
A
N
D
2
0
1
5
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.ssh.forward_agent = true
config.vm.network "private_network", ip: "192.168.33.10"
config.vm.base_mac="0800271AB2AC"
config.vm.provider "virtualbox" do |vb|
# vb.gui = true
vb.customize ["modifyvm", :id, "--memory", “8192"]
vb.customize ["modifyvm", :id, "--cpus", "4"]
end
config.vm.provision :ansible do |ansible|
ansible.playbook = "provision/mainVagrant.yml"
ansible.verbose = "vvvv"
end
end

application in 2015 — Monolith + ﬁrst micro services
F
A
Z
L
A
N
D
2
0
1
5

F
A
Z
L
A
N
D
2
0
1
6
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
config.vm.box = “ubuntu/xenial64”
config.vm.synced_folder "./", "/vagrant", :nfs => true
# vb.gui = true
end
end
end

application in 2016 —- monolith + microservices + DOCKER AS R&D project
F
A
Z
L
A
N
D
2
0
1
6

F
A
Z
L
A
N
D
2
0
1
6

NFS problems during 2016
F
A
Z
L
A
N
D
2
0
1
6

F
A
Z
L
A
N
D
N
O
W
# vi: set ft=ruby :
config.vm.box = “ubuntu/xenial64"
config.ssh.forward_x11 = true
config.vm.synced_folder "./", "/vagrant", :nfs => true
end
end
config.vm.provision :shell, :inline => "sudo rm /etc/localtime && sudo ln -s /
usr/share/zoneinfo/Europe/Rome /etc/localtime", run: "always"
config.vm.provision "shell", run: "always" do |s|
s.inline = '
sudo mount -t ramfs none /opt/sycache -o "mode=0777" ;
sudo service nginx restart
'
end
end

application in 2018 - monolith + microservices
F
A
Z
L
A
N
D
N
O
W

https://github.com/hashicorp/vagrant/issues/8788
F
A
Z
L
A
N
D
N
O
W

https://github.com/hashicorp/vagrant/issues/8957
F
A
Z
L
A
N
D
N
O
W

https://blog.docksal.io/do-not-update-to-macos-high-sierra-if-you-use-docksal-or-vagrant-3ea461805169
F
A
Z
L
A
N
D
N
O
W

FAZLAND … the story so far quick recap

VAGRANT AND DOCKER
F
A
Z
L
A
N
D
N
O
W
Vagrant Docker
Virtualization Virtual machine Linux container
Resource isolation Strong Weak (shared kernel)
Startup time Minutes Seconds
Image build time 10+ minutes mins
Size 1GB+ 100MB+
Sharing Vagrant Cloud Docker Hub

• run on top of VM (hypervisor type 2)
• vagrant manage VM’s
• has complete ISOLATION, guest VM
• kernel separated from HOST VM
• it needs some GB of space
• turn on env in minutes
• Linux, Windows, OSX
VAGRANT AND DOCKER
F
A
Z
L
A
N
D
N
O
W
• uses containers, similar to LXC
• Docker manage container
• less isolation, process isolation
• shared kernel model
• lightweight environment
• turn on env in minutes
• Linux, OSX (slow),

Recap #2
Vagrant - FazlandVm’s and Vagrant

Deployment Pipeline
What is a deployment Pipeline ?

Deployment Pipeline
ANY IDEAS ?

Deployment Pipeline
“It is the process for getting software
from version control
into the hands of your users.”
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.  
by David Farley; Jez Humble

Deployment Pipeline

Recap #3
Deployment Pipeline
Vm’s and Vagrant Vagrant - Fazland

What we have to do ?
The end :)

THANK YOU !

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
Automation. by David Farley; Jez Humble 
Published by Addison-Wesley Professional, 2010
• Continuous Integration: Improving Software Quality and Reducing Risk. by Andrew Glover
, Steve Matyas , Paul M. Duvall Publisher: Addison-Wesley Professional Published: June
2007
• https://www.vagrantup.com/intro/index.html
• https://en.wikipedia.org/wiki/Virtual_machine
• https://github.com/hashicorp/vagrant/issues/8788
• https://groups.google.com/forum/#!topic/vagrant-up/UgINc-ppptU
• http://mitchellh.com/comparing-ﬁlesystem-performance-in-virtual-machines
• https://hackernoon.com/how-to-create-consistent-development-environments-that-just-
work-55be5417341b
• https://martinfowler.com/bliki/MicroservicePrerequisites.html
• https://martinfowler.com/bliki/MonolithFirst.html
References

FAZLAND current Deployment Pipeline
Legacy NG + Api
2 different stacks living together

Legacy NG + Api
2 different stacks living together
both environments uses micro services for sending email,
manage notiﬁcations to browser or mobile app… etc

1. developers works on features tickets
2. developers tests their tickets
3. developers merge the feature tickets on develop branch.
4. Before merge a git pre-commit hook will be invoked and re-
executes all tests.
D
E
V
E
L
O
P
M
E
N
T

If tests fails the branch will not be merged.
D
E
V
E
L
O
P
M
E
N
T
if test succeed the feature branch will be merged on develop.

1. when features branches are merged on develop a web hook is invoked
and a stage environment on AWS will fetch the updates and re-create the
environment updated with the latests stuff.
2. during deployment on stage tests (unit, functional and integrations) are
executed
3. if the process succeed a new fresh Stage environment is ready to be
tested by our Product Team
4. When the Product team Validate the tickets a new release will be created,
the master branch will be updated with new stuff and a new tag is created.
S
T
A
G
E

1. every time a new Tag is pushed on remote, a web hook against AWS is
called. And through AWS CodePipeline we start to deploy on production the
new features.
2. the same thing happen with our legacy environment with the difference that
the deploy is done with Capistrano, on pure EC2 instances.if the process
succeed a new fresh Stage environment is ready to be tested by our Product
Team
3. AWS CodePipeline will fetch the new release, make the build (in fact re-
execute tests) and if they succeed update our AWS ECS, draining old images
and creating new ones.
P
R
O
D
U
C
T
I
O
N

Long life to vagrant… Vagrant is dead

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Long life to vagrant… Vagrant is dead

Similar to Long life to vagrant… Vagrant is dead (20)

More from Federico Panini

More from Federico Panini (8)

Recently uploaded

Recently uploaded (12)

Long life to vagrant… Vagrant is dead