00:00:00.199
Yan Lish and he will talk about infrastructure as Ruby coat please give
00:00:16.000
Applause waiting for yeah the microphone is on so welcome back from lunch I hope I
00:00:21.880
hope you enjoyed it all you need now is someone who talks very slow and softly
00:00:32.040
so I thought um since uh Ruby is most uh known for its VB development
00:00:38.719
capabilities I'd um introduce you to a little niche in Ruby programming which
00:00:44.480
is infrastructure as code and in this case um it's Ruby code in my talk I'm
00:00:51.120
going to first introduce you to the concept of IAC then I'll go into the
00:00:56.600
actual product that um I've been using with my team for 14 years now um we'll
00:01:02.800
go into a very um small practical example and uh we'll finish with uh
00:01:08.759
questions and uh before I get into things a little bit about me I'm Yan um
00:01:15.520
lately I've um tried to get back into teaching and online education something
00:01:22.920
that I did in the early 2000s um at monospace mentor.com you can find my
00:01:29.400
website where I'm going to offer courses workshops and where I'm also building a
00:01:35.240
cozy little devops Community I also do regular live streams on Twitch where I
00:01:41.200
do basically my daily work which is in part um infrastructure stuff and in part
00:01:47.920
um related things and you can also find me on madon at
00:01:53.320
floss. at monospace Mentor infrastructure as code gets
00:01:59.960
interesting once you um don't want to manually configure servers anymore so if
00:02:05.240
your number of servers keeps growing and you don't want to manually SSH into them
00:02:10.319
and uh uh install packages write configuration files try to keep those
00:02:16.360
configuration files somewhat coherent and uh in sync then um at one point
00:02:23.080
you'll probably have the idea well um we need to centralize these things we need
00:02:28.160
to find a way to have Central configuration um we need to be able to
00:02:34.400
maybe version things so that we can see what um uh has changed since last week
00:02:40.920
and uh what's now broken um things like that and that's where IAC comes in which
00:02:47.959
basically tries to um move server management into the same position as we
00:02:54.519
are with software engineering nowadays where everything is under Version Control where where everyone has insight
00:03:01.400
into um uh the code that is actually in production and things like
00:03:07.080
that when I started my day job um a managed housing company in 2010 I knew
00:03:14.480
my number of servers would grow so I was looking for Solutions and the solution I
00:03:20.360
uh eventually decided to use was called chef chef was um started by a company um
00:03:29.319
named Ops Code in the beginning then later they uh renamed themselves into Chef software and if you think the uh
00:03:37.319
recent debacles with open- Source licensing uh that we saw with terraform
00:03:43.159
and redis were new you are mistaken uh in April
00:03:48.560
2019 Chef software um did made a change
00:03:53.640
to their licensing where they said okay we'll um move all our soft sofware
00:04:00.120
licenses to the Apache license but distributions of that
00:04:08.000
software need a commercial license if you use them in a commercial setting
00:04:14.280
which means um you would either have to package uh Chef software yourself and
00:04:20.160
become a software maintainer instead of a software user um or you would have to
00:04:25.479
pay and that of course um uh led to the the now quite common um reaction by the
00:04:33.080
open source community of um forking the whole project and um uh publishing it
00:04:39.840
under a real open-source license and that's exactly what happened here as well and um so now there is an
00:04:47.720
alternative distribution of Chef and all its components or most of its components
00:04:53.120
uh called syn which is a recursive acronym um which means syn is not
00:05:05.080
Chef syn um covers the main components that um make up the whole um ecosystem
00:05:12.800
of Chef that's the central sync server the sync client the uh test um framework
00:05:20.840
called Test Kitchen um then there's sync auditor and sync workstation and I'll
00:05:27.639
get into that and by the way um the whole
00:05:33.440
um ecosystem around chef uses kitchen metaphors um so for example the tool
00:05:40.720
that you use to interact with a chef server is called knife and um there's
00:05:45.759
Test Kitchen the test framework um there are many other uh kitchen metaphors and
00:05:53.080
you can't imagine um how much of a nightmare searching on Google for these
00:05:58.120
tools is
00:06:04.240
so this is how the basic architecture Works um Chef for example different to
00:06:10.080
something like anible uses Central components mainly the chef the sync server I'm going to use sync and Chef
00:06:17.120
inter interchangeably here um the uh sync server uh uses a data store which
00:06:25.039
consists of postgress SQL and redis a search index that initially used Apache
00:06:31.000
solar and now uses elastic search and bookshelf uh which it uses to um uh
00:06:37.560
store the cookbooks and um client nodes which basically is um
00:06:46.080
synonymous with servers then interact with the sync server and um you execute
00:06:53.240
the sync clients on these machines they ask the sync server um what they are
00:06:58.280
supposed to do the sync server tells them and then um you simply run the sync
00:07:04.560
client um on a regular basis maybe once an hour or something like that and um
00:07:10.919
the sync client makes sure that the server looks like um you've described um
00:07:17.440
how it is supposed to looks to look like so in in in the ideal case um if the
00:07:22.960
server already is configured as it's supposed to be the sync client will run through everything see that all is an
00:07:29.520
order and then quit again and um otherwise it will take the um necessary
00:07:35.560
measures to get the server up to speed you can also interact with the sync server as a user of course so um
00:07:43.160
that allows you to uh administrate the whole thing I did mention
00:07:50.039
cookbooks um cookbooks is basically where your code lives so cookbooks are a bunch of Ruby
00:07:57.919
files that uh describe what is supposed to happen and the main part of these
00:08:05.240
cookbooks is the recipes which are Ruby code describing the different resources
00:08:13.360
that um you want to configure and there are a lot of resources I'll get into that in a minute um your cookbook can
00:08:21.840
also provide a bunch of files that you've already prepared and that you want to to deploy on your servers
00:08:30.159
um but mostly if you if we're talking about configuration files there is of
00:08:35.240
course some variability in there and that's where uh chef uses templates in
00:08:41.760
the well-known Erb format um Chef already comes with a large list of
00:08:47.959
resources that you can describe um resources like packages that you'd like to install files that you want to deploy
00:08:55.080
Chron jobs that you want to Define things like that and um if Chef doesn't come with what you need or you need to
00:09:01.880
to have something more sophisticated then you can also add custom resources also written in Ruby to the whole
00:09:09.839
mix something that I ignored for for far too long was
00:09:15.279
tests um I simply did not make the connection
00:09:22.279
um that something that is by now at least ubiquitous in software engineering
00:09:27.760
also should be applied to structure as code um and um deploying changes to our
00:09:34.320
cookbooks was um often anxiety inducing because um running stuff on a um
00:09:43.200
production platform where you get paid thousands of euro per month from a single customer to keep their websites
00:09:50.399
online um and then having a code roll out to hundreds of servers that might
00:09:55.880
break something is um yeah that that is um costing your nerves no no doubt and
00:10:03.360
when after a few years we had decent test coverage things changed significantly and uh we now are pretty
00:10:11.560
confident in rolling out changes even on a Friday afternoon um and that's thanks
00:10:17.800
to a good test coverage in that regard and I'll get into the details of testing
00:10:23.760
uh in a few minutes as well now cookbooks even though you can of course deploy new versions of your
00:10:29.440
cookbooks are pretty static and um there is also data that you want to get into
00:10:36.320
the mix some information might be node specific and by node I always mean
00:10:41.760
server specific um not only do you want to run different cookbooks on different
00:10:47.680
servers for example you might want to run a MySQL cookbook on a database server you might want to run a uh Apache
00:10:56.120
cookbook on a web server things like that but these servers might be different in how many web workers you
00:11:03.240
want to configure or um how much memory you want your mycle database to uh
00:11:10.639
consume and things like that and that's where attributes come in each node in
00:11:16.839
your whole system can have specific attributes that you set and that get used by the cookbooks um of course there
00:11:24.760
are often very um High similarities between servers especially if we're
00:11:30.920
talking about a cluster of web servers you want to have uh uh them to have a consistent configuration and uh that's
00:11:38.680
where you can use roles which also Define these attributes but then you simply go and say okay you are a web
00:11:45.079
server you are a web server to and you are a web server to and all of them get the same set of attributes and even uh
00:11:53.000
the cookbooks that they execute and we'll see that in a minute there's also a way to have um
00:12:00.120
data that is node independent and uh Chef calls them data
00:12:05.279
bags which are basically Json files that you can then use from your cookbooks um
00:12:11.880
they are stored on the shift server as well and um you'll use them for stuff
00:12:17.519
that's not server dependent and more abstract probably for example in on our
00:12:22.639
managed hosting platform each website has its own data bag item adjacent file
00:12:28.839
that has has the list of domains for that website the uh PHP version It's it
00:12:34.040
uses and things like that I already mentioned the buil-in
00:12:40.360
resources Chef comes with everything that's common in system administration
00:12:46.560
probably when you first spin up your Linux server you want to start installing packages and that's why there
00:12:52.360
is a package resource a file resource is a simple way to get a file on disk for
00:12:58.880
example by simply writing some text into it um but the templates are more
00:13:05.079
flexible because they are based on Erb where Chef first replaces placeholder
00:13:10.480
code or even executes um Ruby code um to then finally render this file and write
00:13:17.360
it to disk similar to how rails renders is renders its views as
00:13:23.519
well the service resource is to manage services namely demons that run on your
00:13:29.160
machine so you can say okay start uh MySQL after it's configured correctly or
00:13:35.639
restart MySQL after you've made changes to a configuration file so you can also
00:13:42.639
um make resources dependent on each other for example you can tell um Chef
00:13:49.320
to write a MySQL configuration file using a template resource and say if you
00:13:56.440
have to change this file because for some reason the content of this file had to change then notify the service
00:14:04.199
resource for MySQL to do a Reload of that
00:14:09.720
configuration if you want to do some low-level stuff there's the execute resource that simply allows you to
00:14:16.600
execute a command and uh if you want to go really down to the metal you can also execute
00:14:24.160
bash or Ruby code by um using the uh Aon
00:14:29.639
resources as well there is a Chron resource um and um for everything else
00:14:36.320
I'll refer you to the uh sync or Chef documentation because there's uh a lot more stuff um also for example resources
00:14:45.160
that are specific for Windows hosts and um the nice thing about Chef
00:14:51.639
is that it abstracts things in a way that you don't have to deal with the
00:14:56.880
minute details for example you you can use the package resource on any Linux
00:15:01.959
distribution and Chef will automatically decide um what the package management system uh it is that is supposed to use
00:15:10.360
so if you say package Apache um on Ubuntu it will use apt to install the
00:15:16.680
Apache package and on Fedora it will use dnf to install it you don't have to um
00:15:22.639
build nearly identical codes for different Linux distributions things like that
00:15:30.959
let's get into a simple example how this looks in practice I've chosen a
00:15:36.399
um uh purpose that uh I can highly recommend name namely making
00:15:42.399
backups and uh we'll simply build a skeleton of a cookbook that uses B
00:15:49.440
Matic to set up a backup service so um first time we run our Chef
00:15:57.720
um Cent it probably should install everything that's necessary so that's where the
00:16:04.600
package resource comes in I simply tell Chef to um use the package resource on
00:16:12.399
Bor Matic and I wouldn't even have to tell it uh that I want the install
00:16:17.759
action because that's the default action anyway so just having package block Matic without the block after it um
00:16:24.680
would work just the same and speaking of block um when I started using Chef I
00:16:30.880
didn't even realize that I was using Ruby because I just copied and pasted these things from the documentation it
00:16:37.920
all looked uh pretty uh understandable yeah package bar Matic and between do
00:16:43.959
and end there are the details um that makes perfect sense and only a few weeks
00:16:49.800
or even months in I realized why these files end with RB and uh
00:16:59.560
and uh my love with Ruby begin that
00:17:04.600
day so here's another resource then to uh deploy the configuration file that b
00:17:10.480
Matic uh expects and um as you can see it uh gets just added to the same file
00:17:18.400
we had previously which is bar Matic which is our cookbook SL recipes slash
00:17:24.439
in my case I just um went the lazy root and uh juice show default. RB as my file
00:17:30.919
name and here um the template resource uses a few more attributes than the
00:17:37.679
package resource because yeah that that task is a little bit more complex um the
00:17:42.840
resulting file is supposed to have specific owners groups and a mode I find
00:17:49.200
it particularly convenient that I can write the mode in octal because that's
00:17:56.360
um how things are stored on dis actually and I'm as a system administrator which
00:18:01.559
I've been since 1993 I'm very familiar with these numbers and uh so um I'm
00:18:07.600
always using the uh octal uh notation here uh of course the first information
00:18:15.400
is one of the most important ones that's the source file for the template and as you can see it's an Erb template that
00:18:22.600
then gets rendered as my config do yaml file I can pass Vari to this template
00:18:30.480
which simply get turned into instance variables that I can then uh use inside
00:18:35.559
the template just like you do with uh controllers and Views in
00:18:42.280
rails and um there's something more here
00:18:47.400
because for the config variable I pass in a value that comes from node and then
00:18:55.360
apparently uh it's a nested hash with the key AR Matic on top and then under
00:19:00.679
that the key config and that is a node attribute um note attributes allow you
00:19:08.280
to pass in as many parameters as you want and for example for our purpose
00:19:15.159
here we need a few configuration settings mainly The Source directories
00:19:20.200
that you want to have backed up here so in the note attributes I can simply
00:19:26.919
introduce a uh top level uh Key Bar Matic I'm using these top level Keys
00:19:34.799
like name spaces and uh uh I think it's a best practice to name those um top
00:19:41.360
level keys after the cookbook name that way it's easy to identify which attributes belong to which um uh
00:19:48.280
cookbook and under that I've simply introduced a config key and um which has
00:19:54.440
configuration settings under it that I'm going to use in my configur ation file
00:19:59.520
and I've just in included here one example um which is the array of source
00:20:06.480
directories which I then can reference in my template file um I simply use the
00:20:14.000
uh placeholder notation of Erb to reference um The Source directories key
00:20:21.000
in my config variable which is already uh let's go back here um the hash under
00:20:28.200
bog m config so that's not visible anymore um and um then I simply build a
00:20:35.520
list of my source directories that bogatic is supposed to back
00:20:42.640
up what if we want to introduce multiple configuration files because for example
00:20:49.000
you might want to back up locally and to an external
00:20:54.200
repository well we'll just restructure our configuration um document here
00:21:00.919
instead of having a s a single config key I'm introducing a key named
00:21:06.760
configs which under it has a another hash um with my different configurations
00:21:14.600
in this case a key config one and another one with config 2 and both of them um have their own configuration
00:21:23.440
settings and once you know that Chef cookbooks are Ruby you can use Ruby in
00:21:30.159
your recipes um for example here I simply iterate over my um keys under
00:21:37.760
configs use the key with the name iterator and uh the value behind it as
00:21:44.679
config and then I'm basically using the same template block that I used before
00:21:50.320
but using name for the file name and um again config as my config uh
00:21:59.960
instance variable and uh that way I can write an arbitrary number of
00:22:05.159
configuration
00:22:10.200
files finally I'll simply have to set up a regular backup um schedule using KRON
00:22:17.480
using the um Chron resource that Chef provides me with um it'll be stored
00:22:23.320
under the name bar Matic it'll execute the usual bartic command reference
00:22:28.520
referencing the configuration file that I created earlier and here um we have a
00:22:33.640
few uh additional attributes hour and minute for the timing and the user this
00:22:40.440
uh command is supposed to run under and since I want to um probably back up my
00:22:46.320
SLC directory um I'm running this command as
00:22:52.400
route since we are using node attributes it's a good idea to actually provide
00:22:58.960
default attributes and I can do that from my cookbook directly um by adding a
00:23:05.840
another file under the attributes directory where I simply Define default
00:23:11.640
values for my um different uh attributes that I'm using that way I can actually
00:23:19.200
run this cookbook without manually defining any node
00:23:24.600
attributes um The cookbook comes with hopefully sensible default values
00:23:30.480
already otherwise if I want to change those values I need to tell Chef for
00:23:36.279
this node please use this value for the hour and for this other node please use
00:23:42.279
this hour so that all backups run at the same time overwhelming my backup server for example this manual um assignment of
00:23:51.000
attributes is a little bit tedious and that's why roles make things a little
00:23:56.120
bit easier uh I can create additional roles files either in Ruby syntax or
00:24:02.559
here I've chosen Jason as my format where I can Define commonly used
00:24:08.000
attribute values for example I want all backups to run at 2:00 and um I can also
00:24:14.760
Define the Run list which means um all nodes that have this
00:24:21.120
role in their run list in their local run list will automatically execute my
00:24:28.399
AR Matic cookbook namely its default recipe and that way I can change this
00:24:35.520
Central role if I want to have a different timing it'll apply to each and every node with this role next time I
00:24:42.919
run the chef client finally as I emphasized earlier
00:24:48.600
we want to have some testing uh Chef has a nice test framework called Test
00:24:53.720
Kitchen which either spins up uh virtual machines or Docker container
00:24:59.520
um to first run Chef inside it so it spins up some kind of Linux that you can
00:25:05.720
Define then it installs Chef uploads your cookbook executes your recipe and
00:25:12.880
then it runs a verify the actual test using a tool called um inspec if you're
00:25:20.240
using the commercial version of Chef or Chef auditor if you're using sync they
00:25:26.320
had to change the name for copyright reasons um both are inspired by server
00:25:31.520
spec which in turn is inspired by our speec so the syntax will be very familiar to to most of you uh the
00:25:39.279
interesting thing is that um uh sync auditor can not only test your cookbooks
00:25:46.640
in development you can actually run it on your live servers as well so for
00:25:52.000
example if you have regulations where you need to audit your machines where you need to make sure that not only your
00:25:58.799
cookbooks are working well but your infrastructure is exactly at that State that you want it to be in then you can
00:26:05.320
actually use sync auditor to um verify your own um production environment as
00:26:12.279
well and that's how it looks like uh it's again a combination of describe
00:26:17.640
blocks with um examples in there little bit uh different from ARP but um it's
00:26:23.440
easy to read I I suppose so I make sure that the package box aut Matic has been
00:26:31.279
installed then I check that the um configuration file not only exists but
00:26:37.919
also contains specific values that I can
00:26:43.919
predefine and finally I check that the cron tab actually has an entry that uh
00:26:52.399
needs to be there otherwise um maybe I'll deploy a perfectly working cookbook that uh whose backup command never gets
00:26:59.279
executed which is pretty bad for backup and um that way I can also make sure
00:27:04.799
that the Chron job gets installed with the proper time that of course was only a very
00:27:11.840
simple example you can of course get more complex I don't know how many thousands of lines of Chef code we have
00:27:18.039
in our code repository after 14 years we've accumulated quite a bit um and you
00:27:24.520
can of course also use cookbooks from third party develop ERS there is of course an open- Source Community around
00:27:31.520
this um with cookbooks that you can re reuse and you can also uh apply a um
00:27:39.200
method called application cookbooks where you basically build your cookbooks on the basis of other cookbooks for
00:27:46.480
example um we tend to build very low-level cookbooks for a specific
00:27:51.960
Service uh for example um we have an engine X cookbook that simply takes care
00:27:57.679
of inst installing engine X and uh setting up a a decent configuration file
00:28:02.720
but then we have our own company specific cookbook that uses the enginex
00:28:08.360
cookbook to set up things that are very specific to our company and this separation of course allow um allows us
00:28:15.120
to open source the engine X cookbook because it's very generic but um we keep
00:28:20.880
our own company specific stuff to ourselves because it's only of use to us
00:28:26.200
anyway and of course you can go go wild in creating your own custom resources and that's thanks to Ruby
00:28:33.600
because I really like this what's called an imperative approach where I can tell
00:28:39.320
my chef client exactly what to do I can use everything out of the Arsenal that
00:28:45.320
Ruby allows me to do um just one example is uh over time our recipes grew and
00:28:53.440
grew uh we started doing API calls from our recipes and all kinds of stuff and
00:28:59.200
we ended up basically where we were with say PHP in the early '90s HTML files
00:29:06.880
with lots of code in them uh completely unmaintainable and just like um uh that
00:29:12.640
Community then started separating things with HTML in templates and PHP code separately with object-oriented classes
00:29:19.760
and everything um we've been doing the same where we have libraries that are
00:29:24.799
full of Ruby classes that do all the business logic and then we have Chef recipes where we simply call um the
00:29:32.840
usual Chef resources and instantiate the classes that we've defined elsewhere so
00:29:39.120
you can actually do proper software engineering with infrastructure as code too and uh I hope you'll um have fun
00:29:48.760
exploring this any questions
00:30:04.440
uh when I I mean first of all thank you for the talk uh when I uh used Chef
00:30:09.840
before the fork uh there was the thing with knife zero
00:30:16.039
and knife Solo or solo is it still a thing that you can also have a
00:30:21.720
lightweight infrastructure where you deploy without having the whole you know uh a separate server that manages
00:30:28.519
everything or is this lightweight approach not coming anymore uh I'd have to check on this so
00:30:37.880
uh uh what they're referring to is um as I said uh at the beginning Chef is a
00:30:43.440
very centralized approach you have the client that needs to have a server that tells it what to do so if you have only
00:30:49.919
a few servers you might actually not want to um have a central server with
00:30:55.399
its own database and all that stuff um and for that Chef came with what's
00:31:00.960
called Chef solo which was able to basically um be a chef client that has
00:31:06.960
all the cookbooks locally can read them and execute them of course there will be
00:31:12.080
no Central node attributes or centrally stored data bag items things like that but for smaller uh installations that
00:31:19.440
was enough um uh Chef solo fell out of fashion that's what I know and since we never
00:31:26.039
used it at all um I can't actually tell you if it's still
00:31:33.360
around all right thank you very much on time really um for further questions I
00:31:39.799
have to ask you to come then back to Yan and ask him in the breaks or in the on the party tonight I'll be around today
00:31:46.240
and tomorrow so just hit me up thank you Yan thank you Applause
