WEBVTT

00:00.000 --> 00:13.600
All right, we have, so now we are scaling to two speakers in parallel, so very well

00:13.600 --> 00:16.400
welcome to Manu and Carson from Highlight.

00:16.400 --> 00:24.640
I think they will say something by themselves and, yeah, stages yours, here we go.

00:25.520 --> 00:32.960
Second, hi, I'm Carson from Highlight and we are presenting today to talk about our work with

00:32.960 --> 00:45.120
Ansible. I think we'll be fun with one microphone and two speakers, yeah, we want to present

00:45.120 --> 00:53.200
something about our Ansible and we like to say we still like complexity, so we are still with

00:53.280 --> 01:03.680
Doughgård and Postfix, maybe, yeah, maybe there are very, very nice new technologies coming

01:03.680 --> 01:13.680
up, maybe there's one day time also to switch. Yeah, so we were very happy to see all these

01:13.680 --> 01:21.200
developments, also we had a very good day yesterday meeting in the official mail stuff beforehand

01:21.200 --> 01:27.040
and we're very much looking forward to see how StarWord will be able to scale in these bigger

01:27.040 --> 01:33.680
setups that we are doing and we're also looking forward to Apache James as another option.

01:35.440 --> 01:46.080
So what we usually do is that we have, we have these complex systems and we have to find ways

01:46.080 --> 01:56.640
how to manage that and our choice of the tool was Ansible and Carson started with one project,

01:56.640 --> 02:05.920
one playbook here and another one there and suddenly things moved on and we have created quite a

02:05.920 --> 02:15.280
few roads. Yeah, over the time, so when the project is good, God complex, more complex and more

02:15.280 --> 02:22.880
complex, we have added much more tools for that. Also, we have customers who are asking for

02:23.760 --> 02:30.320
could you also deploy a web server, could you also deploy our database, our editor server,

02:31.920 --> 02:42.960
also for all groupar and everything. Also, we have very, very different needs on our customer

02:43.520 --> 02:48.880
there's still the customer who comes to us they okay, I want to have a single server with some special

02:48.880 --> 02:57.600
things. There's more companies, they maybe want to have load balancing and high availability

02:57.600 --> 03:04.720
but they only have two servers, it's okay, but they are also big infrastructures. There may be

03:05.040 --> 03:12.800
governmental authorities, there may be universities, NGOs and so they want to be on premise

03:12.800 --> 03:22.880
still and they have special needs for high availability for their databases, they still maintain.

03:26.240 --> 03:32.800
So we have really different needs here. So look here, for the small service, we may be just

03:32.800 --> 03:39.040
need to post-figs, the staff got us to be for main security and the lightweight web interface.

03:40.640 --> 03:47.760
With the bigger things like here, this is typical where we do mostly the main security part

03:47.760 --> 03:57.040
and the main routing in front of something. Something is mostly in our case exchange or then

03:57.040 --> 04:04.480
CRM systems, ERP, there's also main processing. When you look here, it's quickly get complicated.

04:04.480 --> 04:14.800
So we have databases in it, we have special routes for all main security, we have monitoring needs,

04:14.800 --> 04:23.120
we have all the logging, all the firewall things that they're inside. They also want to do

04:23.120 --> 04:32.000
maybe DNS with us. And one of the other needs often is that there has to be a segregation

04:32.000 --> 04:37.040
of the network so that we have something that is in the peripheral and there nothing should have

04:37.040 --> 04:43.280
any access direct access to some databases or anything like that. So this is also one of the needs

04:43.280 --> 04:53.680
that why we still have this kind of more elaborate setup or as we were saying before with a

04:53.680 --> 05:01.520
big shopping list to refer to the earlier comment. The other thing is that also our setup works well

05:01.520 --> 05:09.360
for ISPs and universities where the big change to the previous is that we're also having the

05:09.440 --> 05:17.920
backends to ourselves so that the central component of the off-cut postfix also then will be able

05:17.920 --> 05:29.280
to store the mails in our own backends. And here also the groupback comes in where we also have

05:29.280 --> 05:36.240
then components like there's a web server in front that the groupback itself was often many many

05:36.800 --> 05:44.080
possible options you can set. And there also the every customer has his own needs.

05:48.160 --> 05:54.320
Yeah, why we choose Ansible. We are at handling, we are doing mostly consulting.

05:54.880 --> 06:03.600
So we do the projects with our customers, we enable them to to deploy such systems to

06:04.400 --> 06:11.600
configure and administrators or systems. So we also tell them how all the things work so they can do

06:12.800 --> 06:21.200
so they can maintain the infrastructure alone afterwards. As consultants it's the best thing is

06:21.200 --> 06:27.600
we become in deployed something and go out. And Ansible is perfect for that because it does

06:27.600 --> 06:38.720
not need any local service just needs SSH to the system. Also Ansible is very good together

06:38.720 --> 06:50.320
facts from network so like live IP addresses like local certificates and so on. So we can

06:50.320 --> 06:57.840
gather all the information from all the VMs from all the containers we have and put them together

06:57.840 --> 07:06.080
and write them back. Think of a list of IP addresses. So you have a front and server which needs

07:06.080 --> 07:12.320
all the addresses of the of the back and server to put it in the list. So they can be

07:12.320 --> 07:20.080
they can be reached if possible so we can have an easy load balancing maybe.

07:21.200 --> 07:34.400
Also we found it easy to maybe create passwords in the rollout or yeah also he's certificates

07:35.040 --> 07:41.680
also on the other hand we have wrote some some roads which have some features other roads

07:41.680 --> 07:51.040
maybe not have like here. The example when I have a roll for the Google so go it can

07:53.360 --> 08:00.480
it can include the roll for for an SQL server creates a database creates a user for itself

08:00.480 --> 08:06.160
and maybe also put in the other data for the tables.

08:07.520 --> 08:16.880
Yeah next thing as consultants we we don't say okay we just work with dbn or with zuzu you have to

08:17.920 --> 08:26.160
you have to work with our with our favorite distribution so we we go to the to our customers and

08:26.160 --> 08:33.920
they have dbn Ubuntu redhead in all flavors sometimes zuzu so we have to all cover that.

08:37.520 --> 08:44.960
Yeah and so the way we have set up the whole thing is that actually these specific roads are

08:44.960 --> 08:51.520
available and continue to be developed and they are added as submodules into the bigger project

08:52.000 --> 08:59.200
and by that we can continue to develop and their customers are able to and the users are

08:59.200 --> 09:07.920
able to get the latest features from these roads. So what we do is we we bring this toolbox

09:07.920 --> 09:13.440
become to a project and we configure and talk with the customers on what actually their exact

09:13.440 --> 09:22.240
needs are and then we configure the setup and basically in the end once we have that we just have to

09:22.240 --> 09:30.640
add our different servers into the different groups and by that we're defining their exact

09:32.720 --> 09:39.760
what they need to do and we roll out so by doing this we easily can scale and add servers

09:40.720 --> 09:48.960
just at the go. Also what this means is that disaster recovery all we need is a new machine

09:48.960 --> 09:57.600
with where we can log in by SSH and and the moment we can roll out the Ansible whole completely

09:57.600 --> 10:10.160
again and everything is back to the previous state. Yes so another one of the things that we often

10:10.160 --> 10:17.520
have a need is that in these bigger setups we have to have different roads so we have a development

10:17.520 --> 10:23.920
part where early adopting features can be tried we have a testing and then we have the production

10:23.920 --> 10:34.880
so that everything that goes into production has gone through thorough Q&A and so the customers

10:34.880 --> 10:43.520
actually have a very very flexible and easy thing. We wanted to the onboarding itself is just

10:43.520 --> 10:49.600
by forking our initial template project and with this all of the submoves are already available

10:49.600 --> 10:57.200
and then we do this configuration and we have maybe some custom settings and some custom files

10:58.400 --> 11:10.560
and here we wanted to show something so let's see if that we get logged in.

11:19.600 --> 11:47.600
Okay then the question. We just the question was where the Ansible say roads now for now

11:48.160 --> 11:58.000
a published we just tried to publish it today on open code it's a German repository for

11:58.000 --> 12:08.320
software for the German government thing yeah it didn't went so well because we had several

12:08.320 --> 12:15.520
errors while uploading them so they are not completely there but we will fill it up in the next days

12:18.560 --> 12:26.880
and so we will have to continue with the application like this. Okay so no don't you're

12:27.440 --> 12:40.960
today sorry yeah yeah so the roads and in this Ansible this is the thing we we're all

12:41.040 --> 12:53.520
are yeah how to say how our work was going in we've counted again I think there we had

12:53.520 --> 13:04.000
now 44 roads and other roads are then like shown in the first slide they're typically we have

13:04.000 --> 13:10.240
something like post weeks we have Daphcaut but when you have maybe post weeks you want to have

13:10.400 --> 13:17.280
a small extra service like publish it wait also in the end we didn't even have that but

13:17.280 --> 13:27.520
as an example so this is all covered by one roll the one roll and you will we will be always

13:27.520 --> 13:36.720
created out of a template so they have basically all the same default options and default us so

13:36.720 --> 13:42.800
it's when you create a new one you just edit the list of packages that should be installed

13:43.840 --> 13:54.800
there's a default task to add files remove files also for creating new passwords or asking for

13:54.800 --> 14:00.320
for the passwords like when you have secrets license files and so on it will be

14:00.640 --> 14:09.200
will be encrypted locally and put also on the on the server side we have things like setting

14:09.200 --> 14:15.760
up the firewall IP tables well if you want so you roll has the information which which ports

14:15.760 --> 14:23.760
are needed so it can open the the specific port and just for all the systems which need to access it

14:23.760 --> 14:35.040
yeah so the previous saying templating configuration files for for the service also activate

14:35.040 --> 14:43.600
deactivating we we love to work with ETC keeper as it's making get repository out of the ETC

14:44.000 --> 14:53.120
directory on on Linux systems so you have the whole history in in a local get and we also started

14:53.120 --> 15:01.360
to do something like configuration dumps locally so you always have the latest

15:02.480 --> 15:09.280
config dump from from the system and also try to start to write out in

15:11.200 --> 15:17.600
write out documentation automatically so in in the end when you roll out the whole cluster you

15:18.400 --> 15:25.840
we could create a big manual how to manage and how to manage the cluster later and how it is installed

15:29.840 --> 15:35.280
yeah i do ask a keyboard i always use the us keyboard and i put a stupid password

15:35.360 --> 15:49.520
okay so for our here we wanted to show you what so our basically this template looks like so we have

15:51.120 --> 15:58.000
various locations that can be done so in the import and the roles and modules is all of these other

15:58.000 --> 16:08.480
roles that we are just importing as get sub modules and then for what we actually only have to do

16:08.480 --> 16:21.040
is in the inventory and the hosts we have this any style configuration file and here we can define

16:21.840 --> 16:30.240
very simply what which server will actually have which kind of roles so the post fixed one

16:30.240 --> 16:36.880
mail example is in the mx and then if we wanted to have another one it would be in the mail out

16:36.880 --> 16:44.080
and so on so it's very very simple and easy and also horizontal scalable just by adding more to the

16:44.080 --> 16:50.240
same group same as if you just want to have a single server just put in every group the same

16:50.240 --> 16:59.040
server name you rest the standard automatically by Ansible okay but that's a bunch of

17:03.600 --> 17:13.360
photos yeah five minutes and also you see here we have the files for the files for

17:13.360 --> 17:20.480
is for custom files so we bring default configuration files with us they will be template it was

17:20.480 --> 17:27.840
very events and so on and if you want to have a custom configuration extra or override any template

17:27.840 --> 17:38.000
file we bring in you can put it under files and they will be automatically overruled our yeah

17:38.240 --> 17:54.240
this will overrule our our default templates yeah a set specific for different distributions

17:55.760 --> 18:01.920
and we decided to to take our template also for very small routes just wrote one for a

18:01.920 --> 18:10.560
memcage maybe eight options also eight variables to set also it's nothing more general then

18:10.560 --> 18:17.920
installing one package and drop one file on the other other side but we find it very easy to

18:17.920 --> 18:27.200
still still use our template as it's look like the same in any case so it's more easy to

18:27.200 --> 18:36.640
to understand in the end if all rules follow the same rules yeah this is when when we wrote out

18:36.640 --> 18:43.040
to come complete cluster in the in the end was with Ansible this takes some some time maybe

18:44.320 --> 18:55.200
30 minutes maybe 60 depends more on the or on the latency on your SSH then then about Ansible

18:57.280 --> 19:08.480
yeah here's a link maybe you can click on it as said we we started the it's a morning to

19:08.480 --> 19:16.800
to push them and then there was an error at open code those roads are not perfectly fine

19:16.800 --> 19:26.800
in always as always they're missing much of the documentation we try to to have like

19:27.840 --> 19:37.120
like a template version for the for the roads there they're not all in with the same skeleton

19:37.120 --> 19:44.080
let's say but we will update them in the next days also we will put all the missing

19:45.680 --> 19:51.680
all the missing roads online and what what we still have to decide where we want to go with

19:52.640 --> 20:00.080
where we will have our issue tracker and so on but we will publish that maybe here

20:00.880 --> 20:07.920
but I think also in our blocks of fair and so on yeah thank you

20:08.880 --> 20:30.960
yes so I very much like maybe you can repeat the question then so okay so my question is

20:31.680 --> 20:36.800
when I work with Ansible I somehow get the feeling that I'm always not sure how to avoid

20:36.800 --> 20:42.240
configuration drift over time so an example would be you create a follow-up Ansible with some

20:42.240 --> 20:48.240
files in it then you do version two of your roll and do you then put the deletion of the

20:48.240 --> 20:54.160
folder in version two so are you taking all the stuff that you did in the past with you are

20:54.160 --> 21:00.160
do you just change the flag from to absent or how do you handle this section everything

21:01.360 --> 21:09.200
the question was how to work with config files that are missing in the next version so

21:09.840 --> 21:15.280
how to delete something like that so Ansible is about how to what to do on the system

21:15.280 --> 21:21.680
and it does not care about fire sets that are not needed in the in the new version let's say

21:22.640 --> 21:28.880
this is why we have created a default list in every roll where you can put the paths in

21:28.880 --> 21:31.280
which file or which directory should be deleted

21:34.800 --> 21:41.920
everything we're going to ask about meet again if you have used it for connecting or if you have an

21:41.920 --> 21:48.400
experience because we are currently put screen to implement it in our Ansible and

21:49.040 --> 21:53.280
like know how to answer all the experience from the project

21:55.040 --> 22:01.360
yeah question was about our experience with my to gen my to gen is a

22:03.200 --> 22:08.240
tool framework to which can speed up Ansible very much

22:09.600 --> 22:18.080
when it's working it's fun it speeds up really up to five times so I'm switching

22:18.080 --> 22:25.840
constantly so currently it's somehow not able or was my to gen somehow not able at least in my

22:25.840 --> 22:36.560
installation to install packages all other stuff is working so when yeah depends sometimes

22:36.560 --> 22:43.120
I switch to the GitHub version and go back afterwards it's not for a stable environment

22:49.040 --> 23:10.960
so the question was yeah so the question was if open code will be our central

23:10.960 --> 23:20.320
available with the community to also accept merge requests and so on we haven't made up our

23:20.320 --> 23:26.560
mind completely about this we wanted to go for the event of first and have it out so that's why

23:26.560 --> 23:35.440
and we open code will be available for so our playbooks will be there it is not 100% sure that

23:35.440 --> 23:40.080
we will use this as the main form with interaction with the community but we will publish it on our

23:40.080 --> 23:44.320
blog and then also update it here okay yes then one more question

23:55.680 --> 24:01.360
so the question was regarding updates if it and then if it would then kill the server and

24:02.880 --> 24:10.000
bring it back up so yes we have changes that require a restart where we have a handler

24:10.480 --> 24:19.200
and this handler wouldn't be called so when we use we then go to production we have

24:19.200 --> 24:23.840
Ansible to go in serial so that this doesn't happen to everything at the same time

24:25.120 --> 24:30.160
okay any further questions yeah okay this

24:30.160 --> 24:45.360
so the question was how we test our roles after a change for example adding a new operating

24:45.360 --> 24:53.920
system version not automatically yet so in the future we will have pipelines that will

24:53.920 --> 24:58.000
run against those things to see that these basic functionalities will be there

24:58.880 --> 25:06.320
yep so the idea is so you can update the roles and follow the change lock and nothing will

25:07.440 --> 25:13.520
break in the end and we need a bit much bigger testing platform before that yep