Hi, my name is Mats Iremark.
I work at SKF Group as a cloud
and infrastructure architect.
SKF is the world's largest and most
well known bearing manufacturer.
We supply to over 40 industries globally and
have 100 plus factories across the world.
I'm going to tell you about and
show some of the cool stuff that
we've been doing for the last 12
months. A little over a year ago,
we started big digitalization journey
with the goal of building up a super
modern hybrid cloud environment. As of today.
We've set most of the standards
on how we want to do this.
We built this up on the latest and greatest
of the Microsoft Azure hybrid stack.
Of course, the Azure Azure Cloud
and to allow compute at the edge.
We've been early adopters of the Azure Stack.
HCI and Azure Stack edge.
We've had focus on managed Services,
AKS in Azure,
and AKS using the Azure Stack HCI. Database
offerings like Ark Data Services,
an SQL Edge are core components in our
Platform and we're also using the Azure
API management for the governance of APIs.
We made it as easy to run a Hello World
container in the cloud as it is to
run a mission critical containerized
application that controls how and
when our bearings are produced.
Moving an application from a dev state.
To production is no more work than
adding a few lines of code or config
into Git repository and passed the
necessary test or approvals on the way
We are utilizing the latest technology
frameworks and ways of working as a
demos Terraform for infrastructure
Jsonnet and Helm for configuring
containerized applications.
GitOps as the workflow to
allow increased productivity,
visibility and security.
ArgoCD as the GitOps operator
managing deployments to
all of our hundred plus factories,
the central team here at SKF,
or as we call it the central
or global factory.
Set up and monitor Kubernetes
clusters belonging to each factory
in the cloud and on the edge.
We provide a computer components needed
before cluster is production ready.
On top of that,
we allow developers to deploy their apps
via Git OPS and run them in a secure way.
I'll soon give you a short insight into
how we deploy Azure API management.
Local gateways to production in two
factories and also have a look at
our Big Terraform repository which
holds most of our cloud infrastructure.
Now I'm going to show you a real
world example of how we deploy the
local gateways for API management
service to our factories.
The scenario is that we have an API
management services running in the cloud.
We have set up.
Local gateways for the Swedish,
the Austrian and Italian factory.
In this demo I will deploy the API
management local Gateway Gateways instances
to the Swedish and Italian factory.
We're doing this the GitOps way
way we're using ArgoCD,
which fetches its manifest from
repositories in Azure DevOps.
So let's jump into the code.
We have a repository called Kubernetes
Cluster configuration here.
This repository contains all the
configuration for all our platform
components for all our clusters across SKF.
Under clusters folder we have a
list which will be pretty long
of clusters that that we manage,
and under each and every cluster.
Here we have folders for the
platform components mode.
Many of these folders are
automatically created,
so it's not a copy paste job for us.
If we go to the API management
folder here we can see that we
have a few lines of code.
We're using Jsonnet to
generate the manifests.
If we run this Jsonnet file,
it will generate manifests for us.
We can also do it with Kube CFG
to get them in YAML format.
This little piece of code is calling.
Some central code under lib apim.
And that code looks like this.
Jsonnet looks very much like
Jason with some programmatic
things that that you can do.
With it like if some bots and using
variables send merge strings etc.
So this is this is the code that we're
using to underwrite the manifest.
We just pass a few different values
depending on which which factory it is.
Let's jump over to ArgoCD now,
ArgoCD is the GitOps operator and.
This is an application in ArgoCD.
And we have said here that.
The target for this deployment
is the ASE Azure Stack Edge.
Kubernetes cluster in the Italian
factory and the manifests for
it is in a git repository.
In this path.
And we can see here that ArgoCD has
picked up that there is a config map.
There is a service.
There is a deployment and there
is an external secret specified.
Their external secret is a is a
component that we used to be able to
put secret values in Azure Key Vault and
used inside our Kubernetes clusters.
It's it's a solution that works
equally both when you are on
the edge and and in Azure.
We have the same setup here
for for an AKS cluster running
on Azure Stack 8 CI in the
Swedish factory in Gothenburg.
So let's click sync here for
both these applications.
We will see shortly here in
in the Azure portal that.
These nodes that starts up in these
different factory reports into the
central instance in the cloud that
they are alive and are ready to
accept connections and they will
fetch their configuration from
the central instance in the cloud.
Now we can see here that they
have just reported in that they
are up up and up and running.
So that was real world example of
how we deployed API management local
gateways to one factory in Gothenburg,
Sweden and another one to one
of our Italian factories.
Now let's showcase how we can make updates.
On a global global level here.
If we go to our.
Code base for these manifests for API
management and we basically we change
here that the variable image is this one.
One point 2.1 instead of one point 2.0.
We do git status.
git app, git commit.
Now I'm doing a direct push to master here.
Yeah, this you can do in many different ways.
The most common way to do it is
via pull request and if we're
doing this outside of the demo we
do of course do it with pull
requests that is being reviewed.
By the right team.
So what's in Git has changed.
Now the desired state of our API
management local gateways has
changed and if we do a refresh
in Argo City we can see that.
ArgoCD wants to update
this from one point 2.0 to
1.21 and we can do sync here.
OK, see here that the Newport spins
up and the the old one. Yeah it was
just removed that same same here.
And we can see in the Azure portal here.
That the node it's a new node
with a new version. Reporting in
the same for the other factory.
Yep, that was everything I wanted
to show about how we deploy and
manage API management local
gateways using ArgoCD as the GitOps
operator, repositories in Azure,
DevOps and managing the actual
configuration for API management service.
This second demo will be a
short code introduction to our
main Terraform code repository.
So we prefer to use Terraform
for managing infrastructure.
It follows the Getopts workflow,
and it's a really powerful tool
to manage infrastructure at scale.
We have this repository called
infrastructure initial Dev OPS.
Under the folder digital
manufacturing we have.
One subfolder per region.
We have East US, West Europe and
work is ongoing right now too.
To set up the 1st.
First factory in Southeast Asia too.
If we take a look.
Under each region here we can
see that we have added the
factories that has been unrolled
to this new way of working
with with infrastructure.
Under each and every factory,
we have some folders.
For each environment dev and prod,
and for each environment we also
have subfolders for the different.
Terraform Workspaces that
that we that we have.
We prefer to keep the Terraform code
separate into smaller pieces to allow.
Yeah, basically it's easier to work
with smaller porch with smaller parts
than one big Terraform Monolith.
To each and every. Workspace.
We also have pipelines set up,
so for each factory here
we have pipelines that.
Triggers when you want to make changes.
Let's take a look here at a pull
request that happened some time ago.
We on boarded a new site in in Spain.
To this to this repository and when
working on these changes here.
We can see that pipelines for.
For the different Terraform Workspaces,
Ran and for the pull request to be approved,
Terraform plan must be able to run
and then when the pull request is
approved and the code hits master,
the pipeline triggers again in a
different mode and it will run.
Terraform apply and actually
build all the infrastructure.
So. If we go back to this repository.
The Terraform code in this
repository describes for all our
regions and all our factories,
the current state of all the infrastructure
in Azure and some on the edge 2.
It also allows for people working with
different factors to make pull requests,
requests to to update the infrastructure.
It allows for a central team
to review the changes to make
sure that everything is correct.
Since we have all.
The factories in this single repository.
It also allows for knowledge
transfer between factories.
If if a team at one factory has
created some infrastructure,
it will be visible to all
other factors and they can.
They can use the same the same solution.
Yeah, I think that was everything
short introduction to our
Terraform repository. Thank you.