Streamlining DevOps: infrastructure as state at Air France KLM [DEV2716G]

[jedjebari]

Streamlining DevOps: infrastructure as state at Air France KLM [DEV2716G]

Speakers:

Jerome Djebari (Dev Tech Lead, Air France-KLM)
Jean-François Gueyffier (Ops Cloud engineer, Air France-KLM)

Time: Thursday, Nov 9 2:30 PM - 3:10 PM PST - SFMOMA Theater

At Air France KLM, we started our cloud journey two years ago with 1,200 applications. Since then, we have built a far more mature DevOps practice, but sometimes key responsibilities are shared between developers and operations teams—and that can make automation challenging. For instance, our operations team provisions Azure Application Gateways via Terraform and declarative automation. But our developers manage all configurations with imperative code, which is non-idempotent and difficult to maintain. Discover how we solved this issue at Air France-KLM by implementing Infrastructure as state, thanks to GitHub Actions and a human-readable YAML contract.

Thank you for joining the session! If you have any questions or feedback regarding what was presented, please feel free to add them in the comments and we'll do our best to answer.

To watch the recording, please click https://www.youtube.com/watch?v=4nqRGpYacuc.👈

[codebydant]

Hi team, wonderful presentation 🎉. We are using terraform in the company and was absolutely amazing to see a different approach with powershell scripts.

I have 2 questions:

• How are you managing misconfigurations when running an apply step? for example, we might have a successful dry-run, but when running the apply step could fail because there is a misconfiguration regarding RBAC or something similar. Is there a case to run a roll-back?

• How does the team work when they need to review a PR regarding update/delete/create infra? the way of working?

[jfgueyff]

Thank you so much @dtcMLOps, we appreciate it.

Here are my answers regarding your questions:
1st one: If something fail during the "apply", nothing is pushed to the configuration thanks to the usage of Powershell. That's the reason we chose Powershell over az cli.

In this use case of the AppGateway, all the configuration actions update the appGW configuration via a temporary variable (this done as design by Azure Powershell command)

Example:
1st: Init Variable that is retrieving the appGW config in a powershell object
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

2nd: Then update this variable with all your configuration actions. For example, a config of Request routing rule.
Set-AzApplicationGatewayRoutingRule -ApplicationGateway $AppGw -Name "Rule01" -RuleType Basic -Priority 100 -BackendSettings $Setting -Listener $Listener -BackendAddressPool $Pool

At this step, nothing has been pushed on the appGateway itself, only the $appGW variable is updated.

3rd: Push the configuration to the appGW (effective change) by injecting the variable $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

If project is not happy with this configuration, they can still revert back to the previous commit id of the yaml "contract" file.

Regarding the second question, here is the process that any project team should stick to:

• the yaml contract file that reflects the configuration in Azure should always be in the main branch
• any change to this file should be done that way:
  . developer should work in his own developer branch to modify the yaml contract file
  . then, test the yaml modification using "dry-run" mode and ONLY "dry-run"
  . once he considered his yaml as okay, he raises a PR to the main branch
  . once validated, the workflow calling the GH action should only be run manually (workflow_dispatch) and again with "dry-run" mode first to be fully secured, and then "apply" can be run.

Hope it answers to your questions. Do not hesitate if it's not.

Regards
Jeff