Learn how to simplify all of your application infrastructure into just a few configuration files then deploy your code on Google Cloud Platform with this course. We will start by learning the core concepts behind Infrastructure as Code, discussing security best practices when working with IaC, and comparing some popular orchestration and configuration management tools.
After that, we’ll implement version control for our IaC configurations, and learn how we can automate deployment updates using Cloud Build Triggers. Next, we’ll learn how to integrate Google Secret Manager to protect any sensitive data in our source code. Then to tie it all together, we’ll walk through Google Identity and Access Management and learn how to monitor our users and resources on GCP.
After learning the basics, we’ll build our own immutable server images with Google Cloud Build using both Docker and Packer. We’ll then explore a practical usage scenario and build a WordPress deployment with Google Deployment Manager. We’ll also deploy a similar WordPress configuration using Terraform to compare the two methods.
I will be working in Visual Studio Code during the demos for this course, but you are also free to use any other IDE you are comfortable with instead. A demo repository is provided along with this course, and while we will be working with some Python and PHP in our examples, you should still be able to follow along with the demos without any background in either of these languages.
- Build server images from a configuration file using Docker and Packer.
- Learn to use Google Cloud Build with third-party build steps.
- Deploy application infrastructure from code using Google Deployment Manager and Terraform.
- Understand templating systems for Infrastructure as Code.
- Implement version control for Infrastructure as Code.
- Learn to protect secret data in IaC configurations using Google IAM role management and Google Secret Manager.
This course is intended for programmers interested in expanding their knowledge about modern cloud-based DevOps workflows. Learning to manage Infrastructure as Code is beneficial to solo developers who need to focus as much of their time as possible on their application code and not on managing infrastructure. Development teams will also benefit from this course, because implementing IaC provides consistent performance across deployments in multiple environments, which greatly simplifies project collaboration. This course will also help prepare the viewer for the Google Professional Cloud DevOps Engineer certification.
- You should already have a Google Cloud Platform account.
- You should have Google Cloud SDK already installed and initialized.
- You should already have Git installed, and be familiar with its use.
- Demos will be shown in Visual Studio Code, but you're free to use any IDE they are familiar with.
- Demos will utilize some Python and PHP, but you're not required to be fluent in either of these languages to follow along with the examples.
Monitoring account activity and application logs. We learned in the previous lecture how there are a number of separate security tools and features scattered across Google Cloud Platform that we can combine to great effect in our projects. When used together, these features provide a coherent approach for securely managing credentials and access to resources across our entire application.
In this lecture, we're going to take a guided tour through the Google Cloud Console and similarly connect the dots between some of the logging and reporting tools available to us there. An important part of application security is simply vigilance and using the tools we're going to discuss in this lecture, we'll gain full visibility of practically everything that happens on our project.
Previewing project activity. The first place we can look is the activity tab right on the Cloud Console dashboard homepage. This feed can fill up with a lot of information about every operation occurring across the entire project. There are some filters we can set to make it easier to find what we're looking for here. This activity view will basically tell us what operation was called when and by whom, but doesn't give us much information about the operation that was actually performed. This view is especially useful to track administrative activity, so you can see what members or service accounts are creating or changing resources on the project.
Viewing audit log details. For more detailed information about our application processes, we can take a look at the logs explorer. We can see log data for all of the Google resources our project uses here and can even get log data and console output from our deployed application here. We can work with a query builder here to help search these logs and save those searches to use again later. The logs explorer is the best way to see the inner workings of your deployments and get a good understanding of what your application is doing under the hood.
Monitoring application errors. Another useful tool we can find nearby is error reporting. While we could constantly monitor the logs explorer for new errors, those same errors will appear automatically in error reporting. Google detects errors in our application logs automatically, we don't even need to do anything special in our source code for this to work. We can then get a sense of when and how frequently these errors occur, set up notifications to alert us of new errors, and link these reports to a bug-tracking or help-desk system if we are using one.
Setting budget alerts. One last very important reporting tool we should look at is buried away in the building settings under budgets and alerts. It can be very easy to rack up unexpected costs on Cloud-based deployments, especially when those deployments span many different services and resources across the platform. It could turn out you have some unexpectedly-expensive operations in your application or perhaps your application doesn't scale up very efficiently under load. Instead of discovering this the hard way when we are hit with that big bill, we can set budget limits for our expected operating costs and get an alert when these limits are exceeded. We can set these budget limits for the entire account, on a specific project, or more granularly for individual services on a project. Then we can define threshold levels where we'll be alerted when we're nearing our budget limits so we can investigate the source of the increased expense right away.
Arthur spent seven years managing the IT infrastructure for a large entertainment complex in Arizona where he oversaw all network and server equipment and updated many on-premise systems to cloud-based solutions with Google Cloud Platform. Arthur is also a PHP and Python developer who specializes in database and API integrations. He has written several WordPress plugins, created an SDK for the Infusionsoft API, and built a custom digital signage management system powered by Raspberry Pis. Most recently, Arthur has been building Discord bots and attempting to teach a Python AI program how to compose music.