The course is part of these learning pathsSee 7 more
There are a lot of different options, across a variety of cloud platforms that are well suited for running specific workloads, such as web applications. Things such as Google App Engine, AWS Elastic Beanstalk, Azure App Services: Web Apps, among others.
However, there are still plenty of times where we need to set up our own infrastructure. And so cloud vendors offer IaaS (infrastructure as a service) options. Google provides us with Compute Engine which allows us to create virtual machines, custom images, snapshots, networks, auto-scalers and load balancers.
If we're going to create and implement an application on the Google Cloud Platform system operations, then understanding these services are going to help us to create highly available, highly scalable applications.
All the major cloud providers offer the ability to set up virtual machines, networks, auto-scalers, and load balancers. Where the Google Cloud is different is in the speed of creating and starting up virtual machine instances. As well as the massively scalable software-based, global load balancer; which doesn't require pre-warming. Google also offers per-minute billing for VM instances, after the first 10 minutes.
So Google has a lot to offer. And if you're looking to learn more about the Google Cloud systems operations, then this may be the course for you.
What exactly will we cover in this course?
Course Objectives: Google Cloud Platform system operations
By the end of this course, you'll know:
How to use Compute Engine to create virtual machines
How to create disk snapshots
How to create images
How to create instance templates and groups
How to create networks
How to use the auto-scaler and load balancer
This is an intermediate level course because it assumes:
You have at least a basic understanding of the cloud
You’re at least familiar with general IT concepts
What You'll Learn
Summary A review of the course
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Getting Started||An introduction to the Google Cloud Platform|
|Networking||How to create and secure Cloud Networks|
|Disks and Images||An overview of disk types and images|
|Authorization and IAM||How to authenticate and authorise users|
|Disk Snapshots||How to use snapshots for point-in-time backups|
|Cloud Storage Overview||A refresher on Cloud Storage|
|Instance Groups||How to manage instances with managed and unmanaged groups|
|Cloud SQL Overview||A quick primer on how to use Cloud SQL|
|Startup and Shutdown Scripts||Using startup scripts to provision machines at boot time|
|Autoscaling||How to automatically add and remove instances|
|Load Balancing||How to balance traffic across instances|
|Putting It All Together||A demo of how to use some of the services we've learned about|
Welcome back. In this lesson, we'll talk about startup and shutdown scripts. We'll talk about what they are and how to us them.
We'll begin with startup scripts, which are pretty well-described by their name. These are scripts that run when an instance is started. Started here means that any time the operating system is booted up, so that covers the initial creation of an instance as well as reboots. Startup scripts are used for things such as installing and configuring software, running operating system updates, enabling services, and other tasks along these lines.
When you create or edit an instance, you can add or change a startup script. Startup scripts are added as metadata. Then we have options for where they'll live. For example, if you want to store a startup script in a Cloud Storage bucket, then you can use the metadata key named "startup-script-url." And assuming that the service account has access to it, it'll pull the startup script from there. You could also upload the script from a local file as well as assign it to the startup script metadata key on the command line.
You can use startup scripts with Windows and Linux. Linux is going to use Bash scripts and if you run into any problems, you can check the logs located at /var/log/startupscript.log.
Windows is a bit different. You can use a batch file or PowerShell script and if you want to store the script on Cloud Storage, it needs to be in a publicly accessible URL. Optionally, you can upload the script directly to metadata, just as you can with Linux. Although unlike Linux, Windows has different types of startup scripts. We have a pre-sysprep and a post-sysprep option and there are different keys that we use for each.
Let's test this out with an Ubuntu VM. We'll install an Apache web server and then we're just going to write some contents to an index.html file. So we'll go through the same VM process as usual. And there's nothing special here, however the important thing is when we get to the metadata section where we can add our startup script. I already have this copied to my clipboard so I'm just going to paste this in and what this is going to do is install Apache and then it's going to dump the contents here into the index.html, which will render on the page once we load it in the browser. So we'll create the image and we'll jump forward to once it's complete. Great, now we're back, we're going to browse to this via the IP address. And there it is, it's nothing fancy, however I'm sure you can imagine the possibilities for this.
Alright, here's what we're going to do, we're going to stop the instance and then we're going to make a change to the startup script, we'll change the text that gets dumped into that index.html and then we'll restart it so that you can see that this happens any time the instance is started. So we'll edit the text and we'll just add this line at the end here to restart Apache after this is all done. Okay, great. Now let's jump forward to when this is started back up. And if we reload the browser, you can see that we have our new text in the paragraph. And there it is.
So those startup scripts are going to run anytime the machine is started, and you can use this for things such as installing a Chef client and that would allow you to have a newly-created instance provisioned by Chef. You can use it to run through a basic security checklist and ensure that all newly-added instances are locked down and if you're using in the instance for batch processing, you could bootstrap whatever resources you need and have the instance register itself with the head note. Startup scripts are a simple but powerful part of compute engine.
Now, we also have shutdown scripts, which are similar to startup scripts. However, they run when an instance is shutdown, or more accurately, the shutdown script will be executed, however, if it runs for too long, it's going to be terminated and then that instance is going to be shut down anyway. So shutdown scripts have no guarantee that they'll complete. So try not to execute long-running processes inside of a shutdown script.
The shutdown script will be triggered by an instance being shut down due to an instances.delete request or instances.stop request to the API or when Compute Engine stops a pre-emptable instance as part of the pre-emptable stop process. Also, when an instance shuts down through a request to the guest operating system, such as sudo shutdown or sudo reboot. And also, when you shut down an instance manually through the console or SDK. Use cases for things like shutdown scripts include backing up logs, copying data to Cloud Storage, or cleanly terminating applications. Startup and shutdown scripts are useful for bootstrapping an app or starting up a process for a batch job as well as cleaning things up on shutdown.
Alright, that's going to wrap up this lesson. In our next lesson, we're going to cover auto scaling. So if you're ready to keep learning more, then let's get started with the next lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.