Create example for an end-to-end deployment of MLZ

[brooke-hamilton]

Benefit/Result/Outcome

To show how to create a scripted, repeatable deployment with multiple workloads and customized settings.

Description

Create an example of an end-to-end scripted deployment that customizes MLZ in ways that we expect customers to deploy real-world workloads.

See #594 for more context.

Acceptance Criteria

• A new example is created in the src/bicep/examples directory.
• Includes customizations to MLZ that come from real-world feedback, e.g., network address updates.
• Property settings are in a Bicep parameters file as described here
• Shows how to override parameters on the command line to show in what order az deployment reads parameters.
• Shows how to deploy multiple templates using the same parameters file (a.k.a. parameters file).
• Includes multiple workloads with non-overlapping IP ranges.
• Can be deployed with a single script, and includes both PowerShell and BASH versions.
• Includes scripted creation of a KeyVault for storing Linux and Windows jump box credentials, automatic generation of the credentials (including SSH key), and passing the credentials to the MLZ Bicep template.
• Includes a destroy/clean script.
• Markdown document describing a recommended process

[glennmusa]

I fully support documenting the parameters file approach.

It seems like we could point users to what it is, and in what order az deployment reads parameters, and provide a sample of how someone could reuse the same myMlz.parameters.json for deploying multiple templates.

You can use inline parameters and a local parameter file in the same deployment operation. For example, you can specify some values in the local parameter file and add other values inline during deployment. If you provide values for a parameter in both the local parameter file and inline, the inline value takes precedence.

^ from the link you provided

[brooke-hamilton]

I fully support documenting the parameters file approach.

It seems like we could point users to what it is, and in what order az deployment reads parameters, and provide a sample of how someone could reuse the same myMlz.parameters.json for deploying multiple templates.

You can use inline parameters and a local parameter file in the same deployment operation. For example, you can specify some values in the local parameter file and add other values inline during deployment. If you provide values for a parameter in both the local parameter file and inline, the inline value takes precedence.

^ from the link you provided

I added these acceptance criteria based on the comment:

• Shows how to override parameters on the command line to show in what order az deployment reads parameters.
• Shows how to deploy multiple templates using the same property settings file (a.k.a. parameters file).

[sstjean]

@brooke-hamilton I like the acceptance criteria. The custom IP ranges and naming are the two most common customizations I've seen.

What is your thinking on workloads? I think an App Service with an App Gateway/WAF in front of the Firewall would be a handy example and would show a fairly complex workload. Thoughts?

[brooke-hamilton]

@sstjean thanks for taking a look at the acceptance criteria. 👍

What is your thinking on workloads? I think an App Service with an App Gateway/WAF in front of the Firewall would be a handy example and would show a fairly complex workload. Thoughts?

@mikedzikowski is working on #293 to configure an App Service Environment that is hosting a web app in a tier 3 with traffic coming in through the firewall.

[mikedzikowski]

Still a bit of work to add, and updates needed on this...but here is my start: https://github.com/mikedzikowski/Tier3. @sstjean

[mikedzikowski]

@sstjean I'd like to go over what I have and get your thoughts if you have time.