Packer: A powerful tool in the PHP developer toolbox? It's up to you!
In short: As a PHP developer, is Packer an essential tool in your toolbox? The answer depends on what you work for.
If you are involved in server-side work (for clients or companies) and do development work at the same time, the answer is yes. Packer can help you very much.
But if you are just a developer and rarely deal with server-side work directly, Packer will not help you much.
Even so, learning the basics of creating a server environment will be of great benefit to any PHP developer. You will encounter these technologies more or less throughout your career (everything you create runs on top of them!). Mastering these expertise will undoubtedly improve your career prospects! At least, you will better understand the work of DevOps colleagues.
If you are interested in this, or you often do manual server-side work, please continue reading.
Key points:
Looking back:
In short #2: If you are proficient in Vagrant and understand its purpose as a tool, please skip to this part of this article.
Just ten years ago, the development of PHP applications was basically like this: the developer uploaded some code to the web server through FTP and then checked whether it worked. If it doesn't work, they troubleshoot, make changes in a text editor, reload the affected file again via FTP, and then see if the changes resolve the issue. If so, they will proceed to the next function or problem, repeating the process (and pray that there will be no errors in the work they just completed). They may also do some FTP synchronization.
This is the workflow for an average independent PHP developer at the time to push code to a development server (or worse, directly to a production server) (in fact, some developers still use the same process today). At the time, building a web server itself was usually someone else's job.
In addition, in that not too far away past, in order for the development team to work together, there might be some form of concurrent version control system, and the team may even set up automatic deployment. When changes are committed to the repository, it is automatically deployed to the staging or production system. This situation was actually the best technology for web application development at that time.
In those wonderful old days, the term continuous integration, virtual machines, cloud computing, infrastructure orchestration, data center automation, and even "DevOps" are basically unknown. They have just been born. Amazon has just started their Internet services business. Remember, this was only ten years ago!
Ah, how simple the time was, right?
No, that's not the case. At that time, development was slower, more cumbersome, and more prone to errors. Servers also always need to be "enabled" for testing, which usually means developers have to wait until the "networker" has a server ready for use, such as the latest PHP version. In many cases, this is often a battle, and for "networkers", keeping the server "operated" is like putting out a fire.
Computing and Virtualization Today:
Now, with computer technology at your fingertips, developers can carry more complex development infrastructure with them. Today, the computing power of laptops or PCs is far greater than that of web servers a decade ago.
In fact, many of the smartphones we have today are more powerful than the servers from ten years ago.
Technology is amazing, isn't it?
As the increasing available computing power, more and more people are beginning to realize that this computing power can be broken down into separate "machines". This allows them to perform completely different operations at the same time. More importantly, computing power can be better utilized, thereby saving resources. These are the main drivers of computing power virtualization.
In other words, today, with the ability to create virtual machines, developers can carry their own development environment with them, no longer limited to other people who have to provide them with the right work environment. More importantly, they can build a complete development environment locally and simulate a complete web server.
This not only makes developers more autonomous, this local development environment has another huge advantage: it is called "development-production consistency" - we are in the newbie-friendly book "Jump Start PHP Environment" This was discussed in detail. Development-Production consistency basically means that developers can develop on nearly the same systems as the application is eventually deployed to a production environment.
Production consistency advantages - It allows developers to write higher quality code because they can do the right thing the right way the first time.
Now, developers can have everything they need to develop highly complex applications in their backpacks, including highly complex development environments.
Obviously, this ability also brings complexity. The virtual server must be built, and the software must be installed and configured. All of this can be very time-consuming, and time is money. This also means that developers may need to learn a lot to run such an environment. This is also time-consuming.
The appearance of Vagrant:
To help developers complete the "building" of their development environment, HashiCorp Inc. launched a program called Vagrant. With Vagrant, development environment configuration is code that can be easily shared, rolled back, and rolled forward. Developers are free to try new things, such as the latest version of PHP, without worrying that the server may take hours to set up or the failure may take hours to resolve. Developers don't have to wait for anyone to create this environment, and they won't bother anyone if the environment completely crashes.
More about Vagrant - Reintroduction to Vagrant: The correct way to use PHP
However, there is still another problem to be solved. While Vagrant is great for building a development environment, it is time-consuming to run, especially with a lot of configurations (see below for more information on configuration). Depending on the software involved, it can take between 2 and 20 minutes to build a box and configure the software.
This time consumption also exacerbates the fact that Vagrant can only build a single box for a single virtualized system (called "providers") at a time. For example, if you want to build your environment locally and build an environment on AWS, you have to create two different Vagrant files and run them separately. This is not actually practical. In short, Vagrant is very good at building a single development environment, and that's all.
The appearance of Packer:
To continue, you must now play more of the DevOps role. Packer puts the task of creating virtualized machine images into a relatively simple central configuration, so you can get the same advantages of Vagrant in automated development environments, but now it can also be used to develop basic images.
Virtual machine images are also called virtual devices. It is a pre-built copy of the virtual machine that can be used to create a new virtual machine. In Vagrant terms, these images are called "box".
If you understand the process of creating your own mirror, you will know that manual operations are very troublesome. If you don't know, you're lucky because you can skip the hassle of building them manually and now you can start using Packer. However, you still need to learn some basics of mirror/server building. Again, this is valuable knowledge for developers and any developer should take the time to learn the basics.
Once you start using Packer and you are already using Vagrant, the first question you will think of is, "What is the difference between Packer and Vagrant?" We have already started discussing some of the differences above. Ultimately, Packer creates images that Vagrant can use to build a development environment. If you have used HashiCorp's Vagrant box before, it's likely that it's also built with Packer.
As a DevOps person using Packer, you can provide the development team with images of the production environment that they can easily develop using. This once again supports development-production consistency and simplifies the development process.
We mentioned saving time before. Packer can also build and deploy these images in parallel. So you can build images for different hosts, your private cloud, and Vagrant almost simultaneously. Additionally, these "pre-baked" mirrors start much faster than the boxes configured in Vagrant. Much faster! If your team has been "enabled" and destroyed boxes, pre-baked software and configured images created with Packer will save your team a lot of time.
The Packer process also makes creating basic images repeatable. This means that your production system has higher quality, as the image reconstruction of VMs can be tested and automated in advance. In other words, Packer helps reduce human error.
When building a mirror, you can also control several subprocesses. We'll discuss them later. You can also read more about Packer concepts and features in the Packer documentation. Note that you can build images for many different platforms. You can also use many configuration programs (such as Chef, Puppet, Ansible) or Shell script configuration software. And, you can do post-processing, such as creating a Vagrant box or pushing an image to the Docker registry (and many more).
Wow... there are too many theories, aren't it?
Let's do something practical to help clarify the concept of Packer and how to use it.
Some Packer workflows:
This is a visual representation of what we are going to do.
While Packer does not require Vagrant to create images, Vagrant is added to the above graph to give you a better understanding of where it is in the "pipe".
To get you started learning the basics of Packer, the goal of the following exercise is to create an image that can run on Rackspace and a Virtualbox "box" file. The goal is to show you that you can generate the same images and configurations for development and use on your (theoretical) production server.
We use Rackspace because it has a very simple backend for managing compute infrastructure, and because it uses Openstack, a standard system for infrastructure management.
We also use Virtualbox because it is a free and widely used local virtualization system. If you prefer, you can use other systems such as AWS and VMWare, however, you will need to modify the materials provided in this tutorial because they are made specifically for both systems.
Please note: The virtual server we built in this article is by no means "production ready". They are for demonstration purposes only.
The initial image we will build with Packer will be a Debian Jessie (64-bit) image with Nginx and PHP7 pre-installed.
Requirements: Before you start, you need to install Vagrant and virtualization software Virtualbox (version 5.0) on your computer. You also need a 64-bit computer. If you are using a Windows system, you should also install Git for Windows so that we can use its bash console.
As I mentioned above, we use Rackspace in this tutorial, so you need to create an account there. Setting up an account is relatively fast and easy.
You also need a relatively fast internet connection, as Virtualbox builds a very large image download (about 250MB). Finally, you need to have about 12GB of free disk space on your computer to complete the entire process.
This article also assumes that you know some basic knowledge of using Vagrant, SSH, and Shell commands, and have some basic knowledge of Linux and virtual machines.
Please follow the instructions to install Packer on your computer.
At the time of writing, Packer 0.11.0 has just been released.
After the installation is complete, enter packet in your (git bash) console. You should see something like this.
Now, we will go to Rackspace and start a server and create a base image. Note: If you have AWS or other Packer support as a cloud host for the builder platform, the steps you need to take will be similar. We introduce Rackspace in this tutorial. Also note that creating a server will charge some fees to your host account. However, the amount will be small. The cost of following this tutorial should not exceed one dollar.
Continue to build a Jessie 8 server and name it "Packer Test". Rackspace is very intuitive and easy to understand. Start a 1GB server to create the image from it.
After the server is active, create a mirror of the newly created server (the "Operation" button in the upper right corner). After creating and saving the image, you can delete the server.
Go to "Server->Mirror" and you should see your new image. Click it to go to the mirror's details page. We will need the mirror ID.
Okay. Now that you are ready for the basic image to use on Rackspace, we will start building our own image. This process is actually quite complex, especially for those who only have limited knowledge of the server environment and Packer. So, to provide some help, we have created a demo Packer repository for you to download. Please clone this repository from your (Git bash) console.
<code>git clone https://github.com/smolinari/PHP-Packer-Demo </code>
Move to the newly created "PHP-Packer-Demo" directory.
<code>cd PHP-Packer-Demo </code>
Use your favorite editor to open the jessie64.json file and enter your Rackspace user credentials and mirror ID.
Quick sidenote: You can also add your Rackspace API key instead of your password. If you really start using Packer, you can also move access credentials to separate files and ignore them using Git. However, doing so is beyond the scope of this article.
jessie64.json file is the core of Packer. This is the configuration file that controls Packer to perform actions. It's similar to the Vagrantfile used in Vagrant (we also provide you with Vagrantfile in the download).
Now run Packer with the following command.
<code>packer build jessie64.json</code>
This build process takes several minutes. Since we are working on the tutorial, let's actually understand what's happening inside Packer while waiting for it to complete. This process should not exceed about 30 minutes, or the output in the console should not stop for more than 10 minutes. If this is true, an error has occurred.
First, Packer starts the build process using the basic image we defined. These images are started as the server itself, and we also define these servers in the jessie64.json file. You can find the specific JSON value of the "builder" at the top of the jessie64.json file.
<code> "builders": [
{
"type": "openstack",
"username": "ENTER_RACKSPACE_USERNAME_HERE",
"password": "ENTER_RACKSPACE_PASSWORD_HERE",
"region": "IAD",
"identity_endpoint": "https://identity.api.rackspacecloud.com/v2.0",
"ssh_username": "root",
"image_name": "Test Packer Image",
"source_image": "ENTER_YOUR_IMAGE_ID_HERE",
"flavor": "2"
},
{
"type": "virtualbox-iso",
"boot_command": [
"<esc><wait>",
</wait></esc> "install <wait>",
</wait> "preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/vanilla-debian-8-jessie-preseed.cfg <wait>",
</wait> "debian-installer=en_US <wait>",
</wait> "auto <wait>",
</wait> "locale=en_US <wait>",
</wait> "kbd-chooser/method=us <wait>",
</wait> "netcfg/get_hostname={{ .Name }} <wait>",
</wait> "netcfg/get_domain=vagrantup.com <wait>",
</wait> "fb=false <wait>",
</wait> "debconf/frontend=noninteractive <wait>",
</wait> "console-setup/ask_detect=false <wait>",
</wait> "console-keymaps-at/keymap=us <wait>",
</wait> "keyboard-configuration/xkb-keymap=us <wait>",
</wait> "<enter><wait>"
</wait></enter> ],
"disk_size": "10140",
"guest_additions_mode": "disable",
"guest_os_type": "Debian_64",
"hard_drive_interface": "sata",
"headless": true,
"http_directory": "http",
"iso_checksum": "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654",
"iso_checksum_type": "sha256",
"iso_url": "http://cdimage.debian.org/cdimage/release/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso",
"shutdown_command": "sudo /sbin/halt -p",
"ssh_password": "vagrant",
"ssh_username": "vagrant",
"ssh_port": "22",
"ssh_wait_timeout": "10000s",
"vm_name": "debian-jessie",
"vboxmanage": [
["modifyvm", "{{.Name}}", "--memory", "1024"],
["modifyvm", "{{.Name}}", "--cpus", "1"]
]
}
],
</code>The builder is responsible for making the mirror you want compatible with the environment you are targeting. For example, using AWS AMI, you can actually build your Virtualbox image for use with Vagrant and AWS.
In our exercise, we are combining the "openstack" and "virtualbox-iso" images. Unfortunately, Packer cannot use the openstack image to build Virtualbox images, so we also created the virtualbox image.
You will notice the "boot_command" section in the above JSON code. Here we are actually in the automation to enter the necessary commands to install Debian Jessie 8 as the operating system in the Virtualbox VM. You can even watch the installation process in Virtualbox when Packer is building, if you want.
Of course, there is a lot of "magic" happening here, you have to really understand the internal mechanisms of Linux installation and Packer's internal mechanisms in order to manually combine such Virtualbox images. Thankfully, there are many excellent DevOps people who provide such Packer .json files to the public.
Once the builder starts the image in the VM in Rackspace and Virtualbox, Packer will start configuring the software defined in the shell script. With Packer, you can also use systems like Puppet, Chef, or Ansible, and many other systems to orchestrate configurations. We only use shell scripts, you can find these scripts in the /scripts directory.
This is the configuration part of our configuration file.
<code>git clone https://github.com/smolinari/PHP-Packer-Demo </code>
"file" configuration program is how we add configuration to the VM. It loads the configuration file on our computer into the /tmp directory on the VM. During the configuration process, there are some commands in the shell script that copy the configuration file to the correct location on the VM. We have php.ini files like Nginx's "default" configuration files or modified PHP. You can find the files we are using in the /transfer_files folder.
You will also notice the "override" section above. This tells Packer to run certain scripts only for each image build. In our exercise, we need to do less processing on the "openstack" image to make it "consistent" with the Virtualbox image, so we only process the setup.sh script.
Lastly, there is the post-configuration processor part.
<code>cd PHP-Packer-Demo </code>
This is responsible for actually building the Vagrant box.
It is important to remember that everything we configure now is "pre-baked" into the mirror. Packer saves us (or our development team) a lot of time with this automation!
After Packer has configured all the software we configured in the jessie64.json file, it will close the VMs and store new images of those VMs. For Rackspace images, you will find a new image in the Saved Images section of the Rackspace Management Control Panel. For Virtualbox images, you will find a "jessie64.box" file in the current directory.
That's it. Packer has done its job!
You can now use the Rackspace image to create a new server. Try it. Go to the Servers section and select Create Server, then go to Saved Mirror. You should see your newly saved image under Deleted Server. Select it and start the server. Once it is active, you can get the IP address given to you and enter it into your browser. You should see the Nginx welcome screen.
For Virtualbox images, we also need to use Vagrant for some work. Read carefully now. This will become very difficult!
In the directory containing the Vagrant file, enter the following command.
<code>git clone https://github.com/smolinari/PHP-Packer-Demo </code>
That's it! OK, we help you by creating Vagrant files for you. You need to learn more about Vagrant in order to create a available file yourself. As mentioned earlier, if you are a serious developer, you should learn this.
You should now see a new image as a VM in Virtualbox's UI.
The first command above adds the new box to Vagrant, so it knows where to use it. We named the box "jessie64" and use the box we just created. The second command tells Vagrant to create a virtual machine in Virtualbox and run it.
You will also notice that the initial startup of the box only takes one or two minutes. If we keep configuring in Vagrant, it will take 10 to 20 minutes. This saves time again.
Once the "vagrant up" command is completed, enter the URL https://www.php.cn/link/14e676072a5b15381b6f7f33c3528215 in your browser.
In both systems, you can also use the "vagrant" user and the password "vagrant" to SSH connection. These servers are not secure!
Let's do something more interesting.
Imagine how many times you have done something similar when you perform the next step. We are now automating the software installation and configuration process!
Let's assume we've done a lot of Symfony development work. Let's go ahead and set up our image so that the Symfony version is installed and ready for it automatically.
Before you start, delete the server on Rackspace. (We don't want to spend any unnecessary money.)
Also, in your console, let's terminate and delete the Vagrant box we just loaded. Enter the following command:
<code>cd PHP-Packer-Demo </code>
Again, let's assume we have a development team that often uses Symfony. Let's automate a Symfony-enabled server. We only load the Symfony demo application, but this extra work should give you a good idea of how Packer helps support development and infrastructure orchestration efforts in automation.
Go to the /scripts directory, open the setup.sh script with your favorite editor, and add the following Shell script code to the bottom.
<code>git clone https://github.com/smolinari/PHP-Packer-Demo </code>
The above code is basically what we need to do in order to properly set up Symfony, PHP, and Nginx.
Comments have been added to explain what will happen in these configuration steps.
After adding and saving the above code, let's let Packer do the heavy work again.
Move up one level in the file system to where we have the jessie64.json file and enter the command we entered earlier.
<code>cd PHP-Packer-Demo </code>
You can now handle other business or have another cup of coffee (or walk around on the treadmill). It will take a while to build a new Symfony demo image.
When you are done, you should see a screen like this.
Now that the image is built and ready, we can start the openstack image as a new server on Rackspace again.
For your Virtualbox VM, enter again the two commands mentioned above under "Create Virtualbox VM".
For the Rackspace server, you will get a new IP. Enter
<code>packer build jessie64.json</code>
You should see the Symfony demo application running.
On your local VM, you can enter the following:
<code> "builders": [
{
"type": "openstack",
"username": "ENTER_RACKSPACE_USERNAME_HERE",
"password": "ENTER_RACKSPACE_PASSWORD_HERE",
"region": "IAD",
"identity_endpoint": "https://identity.api.rackspacecloud.com/v2.0",
"ssh_username": "root",
"image_name": "Test Packer Image",
"source_image": "ENTER_YOUR_IMAGE_ID_HERE",
"flavor": "2"
},
{
"type": "virtualbox-iso",
"boot_command": [
"<esc><wait>",
</wait></esc> "install <wait>",
</wait> "preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/vanilla-debian-8-jessie-preseed.cfg <wait>",
</wait> "debian-installer=en_US <wait>",
</wait> "auto <wait>",
</wait> "locale=en_US <wait>",
</wait> "kbd-chooser/method=us <wait>",
</wait> "netcfg/get_hostname={{ .Name }} <wait>",
</wait> "netcfg/get_domain=vagrantup.com <wait>",
</wait> "fb=false <wait>",
</wait> "debconf/frontend=noninteractive <wait>",
</wait> "console-setup/ask_detect=false <wait>",
</wait> "console-keymaps-at/keymap=us <wait>",
</wait> "keyboard-configuration/xkb-keymap=us <wait>",
</wait> "<enter><wait>"
</wait></enter> ],
"disk_size": "10140",
"guest_additions_mode": "disable",
"guest_os_type": "Debian_64",
"hard_drive_interface": "sata",
"headless": true,
"http_directory": "http",
"iso_checksum": "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654",
"iso_checksum_type": "sha256",
"iso_url": "http://cdimage.debian.org/cdimage/release/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso",
"shutdown_command": "sudo /sbin/halt -p",
"ssh_password": "vagrant",
"ssh_username": "vagrant",
"ssh_port": "22",
"ssh_wait_timeout": "10000s",
"vm_name": "debian-jessie",
"vboxmanage": [
["modifyvm", "{{.Name}}", "--memory", "1024"],
["modifyvm", "{{.Name}}", "--cpus", "1"]
]
}
],
</code>You will see the same content.
It's cool, right?
We looked back on the past and then returned to the present. Hopefully we've made you understand the reasons for computer virtualization, the creation of software such as Vagrant and Packer, and the connection between the two.
If you successfully create two servers, you can also imagine the advantages that Packer can provide you as a DevOps member and developer. These advantages include, but are not limited to:
I hope you enjoyed this article and the exercises of building images with Packer. Please tell us your thoughts on Packer in the comments below.
HashiCorp's Packer is an open source tool that automates the creation of any type of machine image. It supports modern configuration management by allowing you to write infrastructure code and save it in a version control system. Packer can be a game-changing tool for PHP developers. It allows you to create the same development environment, thus reducing the problem of "running on my machine". It also enables you to create ready-to-use images that can be deployed into production in minutes, not hours or days.
Packer stands out for its versatility and compatibility. It supports a variety of platforms, including AWS, DigitalOcean, Docker, Google Cloud, and more. It also integrates well with other HashiCorp tools such as Terraform and Vagrant to provide a seamless workflow for management infrastructure.
Packer is easy to install. It is distributed as a binary package for all supported platforms and architectures. You just need to download the package that suits your system from the Packer website, unzip it, and move it into your PATH.
To create machine images using Packer, you need to write template files in JSON format. This file defines the type of machine and software to be installed. Once the template is ready, you can use the "packer build" command to create the image.
Yes, Packer works well with existing configuration management tools such as Chef, Puppet, Ansible, etc. You can use these tools to configure the software on machine images created by Packer.
Packer has a powerful error handling mechanism. If an error occurs during image creation, Packer marks the image as failed and cleans up all created resources. This ensures that you don't end up with semi-finished or inconsistent mirroring.
Absolutely. Packer is perfect for CI/CD pipelines. You can use it during the build process to create machine images and then deploy those images to your production environment.
Packer provides detailed logs to help you debug problems. You can also enable debug mode to get more detailed output during image creation.
Yes, Packer is an open source project that welcomes community contributions. You can contribute code by reporting errors, suggesting features, improving documentation, or submitting pull requests.
Packer's official website and GitHub repository are great places to start learning. They provide comprehensive documentation, tutorials, and examples. You can also find many blog posts, videos and online courses about Packer on the internet.
The above is the detailed content of Hashicorp's Packer - Is It Something for PHP Developers?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
