 Welcome to this GitHub scorn session. I will talk about how at Orange we are managing dynamic 5G core infrastructure with a FluctCD and Terraform controller. I'm David Blazano. I'm a cloud and software expert for network and tail co-application. I'm deploying mainly 5G networks using GitHub for about two years, and I'm dealing with infrastructure as code for more than five years. So first, before talking about FluctCD, Terraform controller and 5G, I have to give you a little bit of context. Orange is a telco group that is working in more than 26 countries around Europe and Africa, deploying fixed networks and mobile networks to bring communication between everyone and the internet. But what is a mobile network? Just to give you a big picture of what it is, I'll give you some numbers. Orange is dealing with more than 70 millions of mobile subscribers in Europe. All those subscribers are consuming about 800 petabytes of data in Europe per month, and all those subscribers have spread around 40,000 mobile sites in Europe. And the traffic is growing for more than two in three years. We have huge numbers, huge data network that we have to deal with. So the 5G network, this new network, this new mobile way of communication, is not only a big tube with a big bandwidth you can have access from your mobile phone. With the 5G standalone architecture, the standalone mobile network, this is one of the specific 5G deployment we can have. We have a lower latency, we have better improvements of the slice capabilities. I will give you just a few words about the slice later. And we have better support of all this new use case about IoT, VR, and ultra reliable communication. And in this use case, I will talk about the mobile private 5G network. This is a separate network deployed only for our business customers. These private networks are totally separated from the others. They have only their own application, their own 5G function, their own radio. They have everything for them. This is totally separated from the other part. This 5G network is mainly a big set of many 5G core functions in an AWS EKS cluster. This EKS cluster is somewhere in the AWS region and it's connected to local breakout. And those local breakout are mobile sites in the customer zone. They have their own routers, their own application, and their own radio. Those radios are added to cover their needs. And this UPF here, that is a router, is a specific function that allows data to go from a specific pass to ensure that the production needs are not the one of the business needs and the production users are using applications for their own needs and not the one from the business needs. So we have the 5G core functions in an EKS region. We have local breakout with UPF data routers to allow segregated data access from the radio to the application or to the internet for the specific needs depending on the business needs. So we have two kinds of dynamic needs. It's not only 5G core function in the Kubernetes, but we also have to deal with the creation of a new slice. This new slice is a new segmented network. It's clearly a new deployment inside the deployment, a new function deployment inside that. Think about, let's say, it's not a virtual loss in an Apache. It's another Apache, for example. So here it's clearly a new deployment of new application in a new pass to ensure that we have a specific and a secure router for a specific need. So we have to create a new network, we have to create a new infrastructure and to deploy an application inside this network infrastructure. We also have to deal with new radio when customer wants to enlarge its 5G coverage. You have to plug new radio in this site. So we have to securely connect this equipment to the 5G core network. So we have to get Tapsify not only Kubernetes, but also all the infrastructure around Kubernetes, around our 5G core. So to do that, we are using Flux CD Terraform Controller. The Terraform Controller is a new controller of Flux, like the notification, like the customization of the Helm one. It's a controller that will use Terraform resources in a GitHub's way. It will read Terraform custom definitions and create new runners, specific runners to run the Terraform definitions like we have and that we have in the Git repo. This Terraform Controller is multi-tenancy. It clearly allows us to have a GitHub's automation for Terraform. We ensure that what the intent we have in the Git is what will be deployed in the reality in the infrastructure. We also have drift detection, plan and manual approval, GitHub dependencies between Terraform to ensure that some Terraform definitions are run before the others. And we have the variable passing between a Flux CD object like customization or Terraform using secret and config maps. And the last one is clearly one of the key elements we are using to deploy or to use case. So to give you an example of what is a Terraform custom resource, here is a Terraform that I extracted from our pocket. For example, for this new slice, we have a neutral approval to ensure that what we deploy on the Git is what is deployed in the reality. So it's a total approval. Everything is tested. Everything is okay. It's a total approval. The other one is that we want to destroy the resource on deletion. When we delete the intent in the Git, it has to be deleted also in the reality in the infrastructure. We, of course, are using new service accounts. This service account is based on the AWS policy enrol link. So we restrict everything we can just to access that the Terraform can access just what we want on the infrastructure on our AWS deployments. We are using three main other elements. The depends on the depends on how low has to execute this Terraform module after another one. Here we want to deploy this network information after the zone, the zone one. So the two terraform resources will be deployed one after the other. And the two other elements are the managing the management of viable the passing of the viable from one terraform to the other auto customization. Here we are reading for three config to config map and a secret from many. We have config map, for example, for the cluster variables. It's a config map that is a describing what is what is the cluster. Another one to describe what is this slice and the last one to get viable from what was deployed before. And the last one. We have, we have to get information from this script. This script is not only deploying infrastructures, it's also have to to share what has been created the idea of the resource created or some specific network configuration. So we have to write the outputs of those terraform templates to these two secrets to be shared to all the terraform or just to make a customized resources. So the first use case. We have to connect a new radio site or customer business customer want to to enlarge his coverage in his in his site so he plug a new radio antenna. He plug it and we have to to create a VPN between this antenna and the core and then the UPF so this we have first to create an AWS VPN gateway. This is done once once because it's will be used for all the other clients. So at the creation of the cluster, we create an intent to say we want VPN gateway. So it will run a terraform script and this terraform script will create a secret with that is containing just the ID of the virtual the VPN gateway that was created. And when when we create a new site and you write your site with plug the new one, we create a new intent and infrasight one here. For example, with its config map saying that it has a specific configuration and what we have to create and then the name or something of the network information. This customization will create a new terraform resource that will read the variables from the secret, the previous secret and the config map we've just created. The those are variables are inputs for the terraform scripts. And it will be pushed to the terraform to create this last VPN this last VPN client gateway and site to see connection on all the related routes and ACL we have with that. And it creates the last secret to to that all of us to update all network functions because we have to connect this radio antenna to UPF to the router. We have to get information from that antenna to ensure that the network connected to the VPN to the UPF is the correct one. The order use case is the deployment of a new slice. As I said, a new slice is a separated way as a separated place in our network. We create a slice of a network for specific need for a security reason for a specific quality configuration. So this slice need to be created and in order deployment. It's mainly the creation of a new data router of a new UPF. So this UPF must rely on specific configuration. We must create a new network and security rules to have a specific pass for the data. We have to create a specific VM attached to the main clusters on the new network. It will be a new tainted node in the main cluster. But it is a specific node that will host only this UPF for security reason and traffic and data security on this UPF. And we also have to get the lower level network information on this node because this UPF, this router has a specific configuration. It needs to manage huge bandwidth for example. So it has to be connected to the lower level interface and we have to get the PCI addresses for example on the network cards on what we have just deployed. So for that, we just create a new intent, a new definition of a slice. It's a customization and a config map. Those two intents are put in a git and then we create two new customization. Those two customization are the definition of a slice infrastructure and then the slice application. I will not detail the slice application. I will just focus on the slice infrastructure. This slice infrastructure create three elements. We say that we have to create a new dedicated network on security rules. It read the variables from the config map, the slice definition and the cluster vars. And it creates the output to get all the network information in the secret. This secret is also read by the next Terraform definition to create this new EC2 instance. And this new zone attached, this new thing did not attach to the main cluster. It creates also a secret that is passed to the last Terraform definition. This one is quite specific because it's just a Terraform script that has to connect to the EC2 instance to be run inside it and to get the PCI addresses of this new node. So this is a Terraform definition with affinity configuration that enforce the run of this Terraform runner inside this new TNT node. And of course, like the other Terraform script, it creates a secret where it store the PCI addresses of this new TNT node. That's because the application we are deploying in the last customization, the deployment of the UPF or big router need to get the multis configuration on the PCI addresses to ensure that E is connected to the lower level to enhance the UPF performances. So last thing, a few feedbacks about what we are using and the GitHub CIFI way of deploying our infrastructure is succeeded to run for controller. Yes, it's a good idea for us. Clearly, we are just managing infrastructure resources in intents like intents like any other GitHub subject. We have continuous reco-oxidiation, notification, everything is pulled automatically. When we destroy, it's also destroying the infrastructure. We have a dependency between customization and Terraform that are easy to manage. It's easy to deploy application or to ensure to have everything done in a Kubernetes way. And all the variables can be natively passed through Kubernetes config map or secrets between Terraforms and customization. It's a locally an easy way of have a customized template with the possible substitution from flexibility. It's a huge function that allows us to have only template definition of what we deploy and then just get the variables from the local config map and secrets to ensure that what we deploy is in the same way in all the cases, but just with variables. Clearly, our decision to use also Fluid City Terraform controller is because we already had those Terraforms definition. It was previously run in a GitLab CI. It was run once and then it was, everyone say it's okay, it's done. But now it's just, we just take the same definition and put them in the Git and deploy in a GitHub way. But we just modify something in the definition. Variables must be serialized. We cannot inject variables, complex variables like JSON in the Terraform without serialize them. We have to serialize and manage everything like a string if we want to use complex variables. The last element that we have to be careful is the deletion process is a little bit trickier than the deployment. Of course, with all the infrastructures, it's the same thing. Don't cut the branch your own. I said we are using the affinity to get information from another. We also have to ensure that all the other nodes are not running on this node. When we remove a resource, the runner is not inside this resource when we delete it. We just have to take care about this not affinity. When we remove an intent, we have to remove the variables, the variables, config map, or secret after the Terraform intent. It goes when the Terraform runner is starting, it just needs to access these variables. Just take care about that. The last one is not the only alternative to manage the infrastructure. We can also have cross-plane, for example, but here we just need to reuse our Terraform in a GitHub way. It's just the reusing of all scripts. I hope this talk gives you some information and some good feedback that you can bring to your own needs. I wish you a good day.