Article Authors: Trey Burks, Jacob Evans, Paul Jones, Dustin Lee, Aaron Otto, Jonah White
“Failure is only the opportunity to begin again more intelligently” - Henry Ford.
We are a group of six seniors studying computer science at Tennessee Tech University. During the fall semester of 2019, we were given a problem by our client to solve as our capstone project. Podman is a container engine like Docker that allows you to create and run containers that run programs so that you don't have to install anything on a new system. The only issue with Podman is that it is extremely difficult to install on a Mac or Windows PC Our solution to the problem was to create a turnkey solution to install Podman with minimal effort from the user. We started out by creating an ansible script to install and setup Podman. Although we ran into some issues early on, we forged ahead and soon learned that plans can easily be changed. We started on this in the second half of the fall semester and starting out the team had only a single Mac. This would present many issues and greatly slow down the process of developing the turnkey solution because we would only have one point to test our code and debug. This bottle-necked our development during this first semester. However, we would be able to overcome this obstacle if we got some additional Macs. To do this we needed to use the school's resources. The first option was to try and use the cyber range. The cyber range is a variety of virtual machines that are powered by servers on the school's campus. However, due to Apple's terms of service involving the hardware, we were unable to use the cyber range for our virtual machines. After this, we decided to consider using the school's MacBooks. Again, we ran into some issues if we were to use these. Tennessee Tech's technology use policy restricts students from having root access to any of the school's computers. After this defeat, we were left with only the option of using cloud-based virtual machines. There were several providers we looked at. However, the service that best fulfilled our needs was MacInCloud. Once we decided we worked with our professor to acquire the virtual machines. To requisition the MacinCloud VMs we provided a cost estimate to Tennessee Tech along with how long we expected to use the service. Despite our efforts, we would not be able to receive MacInCloud machines until week three of the next semester. While we were working on acquiring the MacInCloud we were also working on starting the project. At the beginning of the project, several decisions had to be made. We decided to use Ansible at the request of the client. We also decided to use CentOS because both Ansible and CentOS are developed by Red Hat. This meant the chance for compatibility was greater. For the virtual machine to run we needed a hypervisor to run the virtual machine on; we decided on Virtualbox initially and later decided on Xhyve. Firstly, we created an Ansible script that would download and install the dependencies we would need or update them if they were not up to date. Second, we had to setup a way to communicate with the Podman virtual machine from our host machine. To do this, we had to configure the Varlink interface. However, we hit our first major technical blocker when the Varlink interface would not correctly connect to the virtual machine via SSH. During this time, we had received word that we were finally going to receive our MacInCloud accounts. After receiving our MacInCloud accounts, we started to work more efficiently on making a script that would use Ansible to install and run Podman, but we began to run into complications. While we searched for solutions, we found that our project had already been created by another person. We got together as a team and communicated with the client, who also acted as our project manager, about our discovery and asked him what he would like to do. He responded that he didn't want to waste our time "reinventing the wheel," so he gave us two options: start a completely new project, or change the direction of our project to making scripts that would install Podman Machine for both Windows and Mac. After talking over the details, we decided that we would rather change the project's direction. Our reasoning behind changing direction rather than creating an entirely new project was that we would likely face more issues getting the resources required for a new project, and since we were in the second semester, would have little development time to make our new project. Since we had two separate scripts to work on, we decided to split our team up into three people: Aaron, Jonah, and Dustin. They worked on making a script that would use Homebrew to install Podman Machine on a Mac and another team of three: Paul, Jacob, and Trey. They worked on a script that would use Chocolatey to install Podman Machine on Windows. Because the scope of these two new projects was less expansive, we thought that smaller teams would be better suited. The split was made mostly for practical purposes though because, although we now had MacInCloud, its performance was spotty in our use of it. As Aaron, Jonah and Dustin eventually found ways to get (or already had) Mac machines they were assigned to the homebrew script. Much like our initial run-in with ansible scripting, this change let to a spike of figuring out how it worked. Fortunately, the Brew documentation was a great help in creating our first and later scripts. Brew is a package manager built to make it easy for people to install programs on Mac or Linux. Our script was supposed to do four key tasks. The first was to install any packages that were required to run Podman-machine. The required software for podman-machine is an emulator in which it spawns and runs its boxes in. Our first idea was to use VirtualBox as we had all had prior experience using it before. However, VirtualBox is a GUI based application and default brew requires GUI applications to be installed in what they refer to as a cask. Unfortunately, this led to an issue as you cannot have a normal brew script depend on a cask. So we were left with two options: make the script a cask project or find a command-line based emulator. With a bit of research, we found the QEMU emulator which had both a brew formulae and drivers for Podman-machine, so it was the logical choice. The next thing the formulae had to do was download the latest release of Podman-machine. This step was relatively easy as the maintainers had precompiled versions of the latest releases provided on their GitHub, so it was as easy as providing the URL and checksum in the Ruby script. Once the program was downloaded the script had to install podman-machine under the correct alias. The default install mechanism for programs on MAC (bin.install) names the alias after the name of the file being installed so renaming the file before to "podman-machine" fixed all issues. When everything was installed the script was supposed to provide post-install instructions on further instructions on how to install the remote client for the machines created by podman-machines. This was done by making use of Brew's caveats mechanism, for every package installed it will automatically place their post-install instructions at the end. What was emphasized as a priority by our project owner was the importance of providing documentation and that was the latest task asked of us. In creating the readme, it needs to be clear what needs to be done to install, how to run and any lines the end user might need to know. Since we decided to use the non-default emulator for our script it was important to state how to change drivers for users that want to switch between VirtualBox and QEMU. Having not known about Brew beforehand, we came to appreciate the community which works to provide easy installation for programs that may be hard to install for the average user. After the transition to implementing Podman with Podman-machine, we decided to create a package that would install Podman-machine, along with all of its dependencies, in a single button press. Achieving this would require us to use a straightforward package manager that could meet these requirements. For these reasons we decided to use chocolatey for the windows implementation of the project. Chocolatey packages make use of nuspec files and PowerShell scripts to install packages. The nuspec file contains essential information about a package such as version, dependencies, and authors, meanwhile, the scripts handle the grunt work of installation, modification, and removal of the package. For our package, we knew that it would be necessary to have VirtualBox for Podman-machine to work, therefore, when making the installation script for our project it would be necessary to have both installed. This was achieved by using Chocolatey's built-in functionality to grab and install what was needed whenever the installation was run. We also knew we would need to make sure that before anyone uninstalled Podman-machine, any instance of it or VirtualBox would need to be shut down. We added this in the 'BeforeModification' script provided by Chocolatey by having a user be asked to close these processes before uninstallation continues. These tools we have created are easy to use and will make it simpler for anyone to setup a Podman instance. When installing, we have two tools you can use to get Podman on your machine. If using windows, you will be able to utilize choco-podman-machine-turnkey. If you are on mac you will be using homebrew-podman-machine. To get started with the chocolatey implementation you just need to follow these steps: open powershell and navigate to the directory where you want the repository files to be downloaded. Then clone the repository using git clone https://github.com/ttu-capstone-podman/choco-podman-machine-turnkey.git Once the repository has been cloned, install the package by running: choco install podman-machine-turnkey - source="'path\to\directory\choco-podman-machine-turnkey'" -y Once you are done you can uninstall by running the command: choco uninstall choco-podman-machine-turnkey If you want to use the homebrew solution, then you can use this command: brew install https://raw.githubusercontent.com/ttu-capstone-podman/homebrew-podman-machine/master/Formula/podman-machine.rb This project was a great experience for all of us, and it was fun to work with real world tools and create something that would be used in the industry. Working on our own turnkey installation with Ansible for so long, only to learn about the existence of podman-machine reinforced why we should work in an agile manner. We were able to switch projects quickly and begin working on our new packages immediately. It also taught us the importance and usefulness of packages to distribute software to users. We all had downloaded packages before, but creating packages provides a different perspective on how much work they are doing for the user. Of course, working on this project has reinforced and possibly improved our teamwork and communication skills. Throughout the project all of us agreed that our communication with each other and collaboration on difficult tasks was impeccable and allowed us to make good progress while keeping the quality of our work to the standard we had set for ourselves. We would like to thank our client, Andrew Roth, for helping us throughout the project, and providing us with valuable insight to the industry that will help us in our future endeavors. We would also like to thank Tennessee Tech for allowing us to have this learning opportunity. We hope that our work is adopted by the open source community and further improved, and that by creating this we have filled a need for a turnkey solution to install podman-machine on both Windows and MacOS.