As a developer, you and your team are tasked with developing an application that you will iteratively update and deploy until it is ready for production. In this example, we use a Wordpress application with generic compute machines for the MySQL server, the Wordpress server, and other components that can be deployed to AWS, Azure, or vSphere-based clouds. This use case uses AWS and Azure cloud resources.
In this use case, you iterate on the same blueprint, adding components, testing, and redeploying the components. The use case starts with a few components, and then helps you modify existing components and add more components.
As you work through this procedure, keep the following information in mind:
The resources and configuration options in the use case blueprint are based on values from Part I (Infrastructure) . In practice, the cloud administrator creates the infrastructure to support the use case but adapts it to your cloud values instead. Work with your administrator to identify the differences.
Because the use case was adapted to your resources, the entries in red are fictitious values that you select or type, but they're also the sample values that'll be cited when necessary.
As with the infrastructure use case, you should adapt this procedure to your cloud resources. In the infrastructure use case, the cloud admin configured:
Two cloud accounts, AWS and Azure.
Three cloud zones. Zone OurCo-AWS-US-East is dev, zone OurCo-AWS-US-West is test, and zone OurCo-Azure-East-U is prod.
Flavor mappings with small, medium, and large for each of the zones.
Image mappings with ubuntu-16 configured in each zone.
Network profiles with internal and external subnets for each zone: devnets, testnets, prodnets.
Storage to support an archive disk, general storage for dev and test, with fast storage for production.
The Wordpress project includes all three cloud zones and any of your users who you want to try this use case.
Verify that you know how the values configured in the