Now that we’ve gone over the basics, it’s time to get our hands dirty and start building some AMIs. The build command is like running Terraform apply with the -auto-approve flag to bypass the user provided input. packer build - kicks off the packer build process. This is similar to Terraform’s validate subcommand and checks for syntax/configuration issues. packer validate - validates packer configuration files.This is similar to how Terraform intializes the configured providers packer init - intitializes packer plugins.Here are some of the basic commands to get going: Packer is similar to Terraform in that executed commands search the current working directory for configuration files and it uses the command plus subcommand format to run. The build block invokes a source or multiple source blocks and then runs additional configuration based on the defined provisioner sub-blocks Packer Commands This will prevent any naming collision between builds and help you diagnose issues when things go wrong. Note: It’s a good practice to included the timestamp in the Packer AMI name to establish a unique naming convention. PackerTimestamp = regex_replace( timestamp(), "", "") You can use bash as a provisioner, but Packer also supports configuration management tools like ansible Source: a code block which tells Packer where to start which is most likely a cloud provider and how to connect to the instance/droplet/vm for additional configurationīuild: a code block which tells packer to invoke a defined source block and run additional configuration on that intance/droplet/vm via provisioners. The two major components of Packer are builds and sources, so that might be a good line in the sand for file organization. I recommend taking some time to think about how you want to organize your Packer files, rather than throwing everything into something like. If you’ve written Terraform code, you know the files end in. Session Manager is an amazing and underutilized tool for managing EC2 instances in multiple ways. An even more secure way to accomplish this is by leveraging AWS’s Systems Manager Session Manager to connect into the instance for configuration. The cost of using this method is additional configuration and a bastion instance to maintain. A more secure way to do this is by using a bastion instance to tunnel through to get to the private instance for configuration. The Packer build process can take anywhere from 5-30 minutes depending on the amount of custom configuration you put into your build. This all looks great on the surface, but take a closer look at the security group and you’ll notice that it opens up the instance to the public Internet which doesn’t feel very secure. The default behavior for Packer is to provision a keypair (for ssh access), instance, and security group on your behalf during the Packer build process. I say most of your configuration because you should not store sensitive information like secrets in your custom AMI. Rebuilding a broken/missing/deleted instance is fast and easy because you baked most of your configuration into a custom AMI. Investing in Packer will bring you closer to immutable infrastructure which is a fancy way of saying you’ll have the ability to destroy an instance and not freak out about it. When the configuration completes, packer shuts down the instance, turns it into an AMI and then does a bit of clean up. Packer builds AMIs by provisioning an instance on your behalf, uses ssh to remote into the instance and configure it based on your specifications. In our case, we’re talking about adding additional configuration to Amazon Linux 2 AMIs. Packer allows you to build configurations on top of existing virtual machine images. Packer also uses Hashicorp’s HCL2 (Hashicorp Configuration Language V2) which should feel similar to writing Terraform code. The link between these two products might be a little loose, but can become a superpower when combined. Packer is brought to you by Hashicorp, the same people who brought you Terraform. Packer can help you build and maintain custom virtual machine images. There are few scenarios where you might consider using a virtual machine over a container (or function.) Maybe AWS doesn’t provide a hosted solution for the technology you want to use, maybe you want to do multi-cloud and the cloud provider’s offerings are too different to manage. Yes, you read that right, but it’s not always a bad thing. The year is 2021 and you’re still building virtual machines.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |