In the most recent Mission Impossible Live Coding event, Jefferson and I convert the GitHub Action Super-Linter to run in GitLab CI. This is a summary of lessons learned and pointers to the results.
Everyone loves Linux for its ability to stick to fundamentals and common platform expectations. Except those of us who do a lot of deployment automation.
Why? Two main reasons: In a world of stripped back distros (think containers), even fundamental Gnu coreutils and other basics can be missing. Which leads to the second frustration - for some reason distro families thought it would be great to not only innovate package management technology but also change up the command set and also not provide a universal command set (like an api) to hide the differences.
So after bashing my head on this a million times, a bit of bash code eventually emerged (yeah from my head). And as you’ll read, it was not a process of random chance and natural selection - but rather it’s opposite - hyper-engineering.
As per Mission Impossible Code Principles I’ve tried to make it “as simple as possible, but still have a very broad scope of reuse”
I’ve been working as a Solutions Architect at GitLab for over 6 months now and I’ve met a lot of awesome people and been challenged by a lot of customer requirements. I work on a great team of solutions architects in a part of the company called “Customer Success”. All of GitLab is keenly interested in customers and their experiences, but I gotta say, I love having it right in the group name! The team I am on really has a heart for customers and works hard to make them successful.
Over time I have realized there are a lot of GitLab users who do not get the benefit of our presales services because they aren’t yet ready to move to paid versions of GitLab or they are just getting started to see what is possible.
This blog started life as CloudyWindows.io because I was generating a lot of sharable Infrastructure as Code and DevOps automation for Windows. While I still do this, my career focus has really broadened to cover plenty of Linux and more and more cloud specific technologies - which is reflected in my blog posts. The one common theme across the previous focus and the new one, is that the coding style I try for is consistently characterized by what I’ve come to call “Mission Impossible Code” (originally discussed here).
While noodling uses for the Ultimate AWS ASG Kickstart and Lab Kit I realized it could use a couple new features and improvements.
The first is to have instances self-tag themselves as to whether they are a spot or on-demand instance. When supporting a mixed instances policy, the implementation requires a little more thought.
A second is the ever common need for a bucket that the ASG instances have access to - whether for AWS SSM results collection or inventory, for deployment artifacts to update instances, access to data or many other uses.
While a relatively small change, the title has also been updated to “The Ultimate AWS ASG Kickstart and Lab Kit” to indicate it is appropriate for experimentation and also as the foundation for a deployable configuration.
I was able unable to avoid the temptation to sneak in a couple other improvements as well.
Since switching focus to the cloud I am doing more and more pure CLI admin of Windows. One of the pains of windows admin from a console is accessing the windows eventlog. Since they are not simple text files like Linux, special PowerShell CMDLets must be used to retrieve them.
Due to the frequency of needing to do it, one of the biggest challenges is tailing an eventlog while waiting for results.
When following a text log, I simply use
Get-Content logfilename -wait to emulate the Linux command
tail -f logfilename
So I went in search of what I thought would be a quick find, but all my finds were all way to long and involved - so I made a new oneliner that follows the principles of Mission Impossible Coding.
A while back I wrote a blog and companion Cloud Formation templates for experimenting with the ways an ELB creation template could be linked to an ASG. That iteration was based on an ASG template designed to show how to kernel patch linux and reboot without termination using ASG Lifecycle hooks.
I had a number of improvements I wanted to make to this template set and this blog represents that work.
The result is really the answer to the question “What would be a minimal, but production-useful working example to learn and experiment with AWS ASGs that use spot instances and proper lifecycle hooks?”
Since the last team I managed had to do all of our automation work for both Windows and Linux, I wanted the solution to work for both.
This post contains the links to my GitLab Commit Brooklyn session “Never Hire a Butler to do a Robot’s Job” as well as an interview I had with Alan Shimel at GitLab Commit.
I’ve spoken at a lot of conferences and I’ve experienced a good number of the many ways that conferences can fail to deliver.
GitLab Commit had three major things working against it that made me wonder what the experience would be like. First of all it was a first time conference for GitLab. Secondarily it was only one day. In my experience, many one day conferences are thinly veiled marketing events with shallow, slapped together sessions. And finally, session slots were 30 minutes - unless it is a 5 minute lightning session, I’ve never seen a session length that short.
My expectations weren’t high, but I was delighted to be wrong on all counts…
Pssst: You can still catch GitLab Commit in London on October 9th or San Franciso on January 14th.
At Infor, my team is responsible for operating a internal, scalable, highly available implementation of Gitlab It is designed for scaling to service our thousands of SaaS developers building hundreds of applications. We have built Gitlab CI Runner deployment automation to supersede our previous deployment automation for a pseudo-high availability Jenkins configuration similar to the approach of CloudBees. We have put together a guide for developers to consider Gitlab CI whenever they have the opportunity to reconsider their CI.
It is not possible for me to count the number of times this code has saved me support calls because I never get those calls ;) A huge part of my work is to build DevOps IaC automation code as tools in a company that runs around 50% Windows and %50% Linux across their many SaaS software stacks.
One of the main types of IaC my team builds is deployment automation for DevOps agents that are designed to run on any of the 10’s of thousands of instances at the company - agents for things like vulnerability scanning, malware scanning, log aggregation and monitoring. Generally these agents are wiring up to an internal or external cloud tenant environment for reporting and/or administration.
Everyday at my job I learn of a new environment I’ve never heard of before that someone is trying to run my team’s code in. Frequently the environment setup is at fault when these DevOps agents error out on their tenant registration calls. After way too many escalations that resulted in the discovery that the environment is at fault - I decided we need to preflight check the tenant URLs we would need to connect to and report failures in logging so that tooling users could easily distinguish when their environment was not allowing endpoint access.
Another common case for endpoint verification is when code depends on public or external package management endpoints for things like yum or chocolatey packages. However, the approach is solid for endpoints of all type whether public or private, local or remote.
If you take a look at a lot of your automation code it may make fundamental assumptions about available endpoints and if it will run in environments that are out of your control, endpoint connectivity validation will save you boatloads of support time :)