Does the Windows built-in version of “curl” confuse or intimidate you? Maybe you come from a Linux or Unix background, and yearn for some of your favorite go-to tools? Newer versions of Powershell include a cmdlet for interacting with the web called Invoke-WebRequest, which is useful, but is not a great drop in replacement for those with experience in non Windows environments. The Powershell cmdlets are a move in the right direction to unifying CLI experiences but there are still many folks that have become attached to curl over the years, including myself. It is worth noting that a Windows compatible version of curl has existed for a long time, however it has always been a nuisance dealing with the zip file, just as using SSH has always been a hassle on Windows. It has always been possible to use the *nix equivalent tools, it is just clunky.
I found a low effort solution for adding curl to my Windows CLI flow, that acts as a nice middle ground between learning Invoke-WebRequest and installing curl binaries directly, which I’d like to share. This alias trick is a simple way to use curl for working with API’s and other various web testing in Windows environments without getting tangled in managing versions, and dealing with vulnerabilities. Just download the latest Docker image to update curl to the newest version, and don’t worry about its implementation across different systems.
Prerequisites are light. First, make sure to have the Docker for Windows app installed (stable or beta are both fine) as well as a semi-recent version of Powershell.
Next step. If you haven’t set up a Powershell profile, there are also lots of links and resources about how to do it. I even wrote about it recently, so I am skipping that step as well. Start by adding the following snippet to your Powershell profile (by default located in C:\Users\<user>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1) and saving.
# Curl alias using docker
function Docker-Curl {
docker run --rm byrnedo/alpine-curl $args
}
# Aliases
New-Alias dcurl Docker-Curl
Then source you terminal and run the curl command that was just created.
dcurl -h
One issue you might notice from the snippet above is that the Docker image is not an “official” image. If this bothers you (security concerns, etc.), it is really easy to create your own, secure image. There are lots of examples of how to create minimal images with Curl pre-installed. Just be aware that your custom image will need to be maintained and occasionally rebuilt/published to guard against future vulnerabilities. For brevity, I have skipped this process, but here’s an example of creating a custom image.
Optional
To update curl, just run the docker pull command.
docker pull apline-curl
Now you have the best of both worlds. The built-in Invoke-WebRequest cmdlet provided by Powershell is available, as well as the venerable curl command.
My number one case for using curl in a container is that it has been in existence for such a long time (less bugs and edge cases) and it can be used for nearly any web related task. It is also much handier to use curl for those with a background using *nix systems, rather than digging around in unfamiliar Powershell docs for similar functionality. Having the ability to run some of my favorite tools in an easy, reproducible way on Windows has been a refreshing experience while sliding back into the Windows world.
Update: Thanks to Torben Kerr for adding instructions for setting up these properties at the multibranch build level rather then for each Jenkinsfile. You can check out his “fix” here.
As the Jenkins pipeline functionality continues to rapidly evolve – the project documentation (or lack thereof), has been a consistent pain point as a user. Invariably, the documentation is either out of date or completely missing. I expect the docs to improve as the project matures, but for now, the cake is a lie. I ran into this roadblock recently, looking for a way to limit the number of concurrent builds that happen in Jenkins, using the pipeline. In all of my anguish, I hope this post will help others in avoiding the tediousness of finding the seemingly simple functionality of limiting concurrent builds, as well as give some insight into strategies for figuring out how to find undocumented features in Jenkins.
While this feature is fairly obvious for old-style Jenkins jobs, a simple check box in the job configuration – finding the same functionality for pipelines is seemingly non existent. Through extensive Googling and Stack Overflowing, I discovered this feature was recently added to the Multibranch plugin. Specifically, I found an issue in the (awful) issue tracker used by Jenkins, which in turn led me to uncover some code in a semi recent PR that basically allows concurrency to be turned on or off. Of course when I tried to use the code from the PR it didn’t work right away. So I had to go deeper.
Eventually, I stumbled across a SO post that discusses how to use the properties functionality of pipelines. Equipped with this new piece of information, I finally had enough substance to start playing around with the code. To make the creation of pipelines easier, Jenkins also recently added a snippet generator, which allows users to build out sample snippets quickly.
To use the snippet generator, either drill into an existing pipeline style job using a similar URL as below:
Or create a new job, and click on the “Pipeline Syntax” link after it has been created to test out different snippets.
Inside the snippet generator there are a number of “steps” to choose from. From the information I had already gathered, I just selected the properties step to create the basic skeleton of what I wanted and was able to use the disableConcurrentBuilds() function I found earlier. Below is a snippet of what the code in your Jenkinsfile might actually look like:
node {
// This oneliner is what limits concurrent builds
properties([disableConcurrentBuilds()])
// Do stuff
...
}
Yep. That’s it. Just make sure to put the properties() function at the beginning of the node block, otherwise concurrency won’t be adjusted right away and could lead to problems. Another thing to note; the step to disable concurrency could just as easily be moved into workflow libraries and applied at the global level and applied at the beginning of all jobs if you wanted to limit concurrency for all pipeline builds, since the code is just Groovy. Finally, the code will disable concurrent builds on a per branch basis. Essentially, if you push many different branches it will still build all of them, it will just limit each branch to one build at a time and will queue up jobs for any commits that get pushed after the initial job has been created. I know that is a mouthful. Let me know in the comments if this explanation needs any clarification.
While I love open source software, sometimes project’s move so fast that certain areas of it get neglected. I am thankful for things like Github, because I was able use it to piece together all the other information I found to come up with a solution. But, I would argue having good documentation not only saves folks like me the time and energy of the crazy searches, it also makes it much easier for potentially new users to look at, and understand what is going on. I will be 100% honest and say that Jenkins pipelines are not for the faint of heart, and I’m sure there are many others who will agree with this sentiment. I know it is easier said than done, but anything right now would be an improvement in my opinion.
If you haven’t heard about it yet, Hyperterm (not to be confused with hyperterminal) is a cool new project that brings javascript to the terminal. Basically, Hyperterm allows for a wide variety of customization and extension to be added to the terminal, yet doesn’t add extra bloat and keeps things fast. For those who don’t know, Hyperterm is based on the electron project which leverages nodejs to build desktop applications that are cross platform.
At its simplest, Hyperterm is a drop in replacement for other shells, like iterm2 or the default terminal app that comes packaged with most OS’s. Since Hyperterm is built on top of node (via Electron) it is by default cross platform so works on Mac and Linux and Windows soon. Obviously this is a win because you can port your configuration to different platforms and don’t need to reconfigure anything, and can also store your configuration in source control so that if your machine ever dies or you get a new one, you have a nice place to pick things up again, which is pretty slick.
If you know javascript, you can already start hacking on the look and feel of Hyperterm, the Chromium browser tools are literally built into it (cmd+option+i).
Installation
To get started, head over to the official Hyperterm website and download the latest release.
Once that is done and you go through the installation process you are ready to get started. Just fire up Hyperterm and you are good to go.
The stock Hyperterm is definitely usable. The real power though, comes from the flexibility and design of the plugin system and configuration files which makes customization really easy to get going with and really powerful.
Configuration
Hyperterm uses its own configuration file to extend the basic functionality. The docs are a great resource for learning more about customization and configuration.
The process of changing themes or adding additional functionality is pretty straight forward. All the plugins that Hyperterm uses are just npm modules, so can be installed and managed via npm. So for example, to change the default theme, you would open up your ~/.hyperterm.js file.
Look for the “plugins” section.
plugins: [],
Add the desired plugin.
plugins: [
'hyperterm-atom-dark',
'hyperline'
],
And then reload hyperterm to pick up the new configuration by pressing (Cmd+Shift+R) or by clicking View -> Reload. You should notice the new theme right away. A nice status line should show up at the bottom of the terminal because of the ‘hyperline’ package, and there was practically no time spent enabling the functionality, which is a big win in my opinion.
For more ideas, definitely go check out the awesome-hyperterm project. This repo is a great place to find out more about hyperterm and other cool projects that are related. The official docs are also a great resource for getting started as well as finding some ideas.
Finally, you can also run,
npm search hyperterm
To get a full listing of npm projects with hyperterm in their name for even more ideas. Outside of the plugins, you can easily hack on the configuration file itself to test out how things work. Again, the config is just javascript so if you know JS it is easy to get started modifying things.
Additionally, you can tweak the configuration by hand to customize things like font sizes, colors, cursor, etc. without having to install or use any plugins. The process to customize these values is similar to installing plugins, just pop open the ~/.hypertem.js file, make any adjustments, then reload the terminal and you should be good to go.
Conclusion
The Hyperterm project is still very new but it is already capable of being the default terminal. As the project grows in popularity, there will be more and more options for customization and the terminal itself will continue to improve. It is exciting to see something new in the terminal emulator space because there are so few options. It will be cool to see what new developments are in the works for the project.
It is definitely hard to adjust to something new but it is also good to get out of your comfort zone sometimes as well. There are lots of things to poke around at and plugins to try out with Hyperterm.
I can’t remember the last time I had this much fun when I was fiddling around with terminal settings. So at the very least, if you don’t switch full time to Hyperterm, give it a try and see if it is a good fit.
I recently attended DevOps Days Portland, where Kelsey Hightower gave a nice Keynote about NoOps. I had heard of the terms NoOps in passing before the conference but never really thought much about it or its implications. Kelsey’s talk started to get me thinking more and more about the idea and what it means to the DevOps world.
For those of you who aren’t familiar, NoOps is a newer tech buzzword that has emerged to describe the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.
Obviously the term NoOps has caused some friction between the development world and operations/DevOps world because of its perceived meaning along with a very controversial article entitled “I Don’t Want DevOps. I Want NoOps.” that kicked the whole movement off and sparked the original debate back in 2011. The main argument from people who work in operations is that there will always be servers running somewhere, as a developer you can’t just magically make servers go away, which I agree with 100%. It is incredibly short sighted to assume that any environment can work in a way where operations in some form need not exist.
Interestingly though, if you dig into the goals and underlying meaning of NoOps, they are actually fairly reasonable to me when boiled down. Here are just a few of them, borrowed from the article and Kelsey’s talk:
Improve the process of deploying apps
Not just VM’s, release management as well
Developers don’t want to deal with operations
Developers don’t care about hardware
All of these goals seem reasonable to me as an operations person, especially not having to work with developers. Therefore, when I look at NoOps I don’t necessarily take the ACTUAL underlying meaning of it be to work against operations and DevOps, I look at it as developers trying to find a better way to get their jobs done, however misguided their wording and mindset. I also see NoOps, from an operations perspective as a shift in the mindset of how to accomplish goals, to improve processes and pipelines, which is something that is very familiar to people who have worked in DevOps.
Because of this perspective, I see an evolution in the way that operations and DevOps works that takes the best ideas from NoOps and applies them in practical ways. Ultimately, operations people want to be just as productive as developers and NoOps seems like a good set of ideas to get on the same page.
To be able to incorporate ideas from NoOps as cloud and distributed technologies continue to advance, operations folks need to embrace the idea of programming and automation in areas that have been traditionally managed manually as part of the day to day by operation folks in order to abstract away complicated infrastructure and make it easier for developers to accomplish their goals. Examples of these types of things may include automatically provisioning networks and VLAN’s or issuing and deploying certificates by clicking a button. As more of the infrastructure gets abstracted away, it is important for operations to be able to automate these tasks.
If anything, I think NoOps makes sense as a concept for improving the lives of both developers and operations, which is one facet that DevOps aims to help solve. So to me, the goals of NoOps are a good thing, even though there has been a lot of stigma about it. Just to reiterate, I think it is absurd for anybody to say that jobs of operations will going away anytime soon, the job and responsibilities are just evolving to fit the direction other areas of the business are moving. If anything, the skills of managing cloud infrastructure, automation and building robust systems will be in higher demand.
As an operations/DevOps person just remember to stay curious and always keep working on improving your skill set.
The new Jenkins pipeline integration in 2.0 is pretty awesome and is a great way to add more automation to Jenkins.In this post we will set up Jenkins so that we can write our own custom libraries for Jenkins to use with the pipeline.
One huge benefit of the new pipeline integration in to the core components of Jenkins is the idea of a Jenkinsfile, which enables a way to automatically execute Jenkins jobs on the repo automatically, similar to the way TravisCI works. Simply place a Jenkinsfile in the root of the repo that you wish to automate, set up your webhook so that events to GitHub automatically trigger the Jenkins job and let Jenkins take care of the build.
There are a few very good guides for getting this functionality setup.
Unfortunately, while these guides/docs are very informative and useful they are somewhat confusing to new users and glaze over a few important steps and details that took me longer than it should have to figure out and understand. Therefore the focus will be on some of the details that the mentioned guides lack, especially setting up the built in Jenkins Git repo for accessing and working with the custom pipeline libraries.
Setup
There are many great resources out there already for getting a Jenkins server up and running. For the purposes of this post it will be assumed that you have already create and setup a Jenkins instance, using one of the other Digital Ocean [tutorials](https://www.digitalocean.com/community/tutorials/?q=jenkins).
The first step to getting the pipeline set up, again assuming you have already installed Jenkins 2.0 from one of the guides linked above, is to enable the Jenkins custom Git repo for housing unique pipeline libraries that we will write a little bit later on. There is a section in the workflow plugin tutorial that explains it, but is one of the confusing areas and is buried in the documentation so it will be covered in more detailed below.
In order to be able to clone, read and write to the built in Jenkins Git repo, you will need to add your SSH public key to the server. To do this, the first step will be to configure the server per the SSH plugin and configuring a port to connect to so that the repo can be cloned. This can be found in Jenkins -> Configuration. In this example I used port 2222.
As always security should be a concern, so make sure you have authentication turned on. In this example, I am using GitHub authentication but the process will be similar for other authentication methods. Also make sure you use best practices in locking down any external access by hardening SSH or using other ways of blocking access.
After the Git server has been configured, you will need to add the public key for your user in Jenkins. This was another one of the confusing parts initially. The section to add your personal SSH public key was buried in docs that were glossed over, the page can be found here. The location in Jenkins to add this key is located here,
Notice that we are using port 2222. This is the port we configured via the SSH plugin from above. The port number can be any port you like, just make sure to keep it consistent in the configuration and here.
Working with the pipeline
With the pipeline library repo cloned, we can write a simple function, and then add it back in to Jenkins. By default the repo is called workflowLibs. The basic structure of the repo is to place your custom functions is the vars directory. Within the vars directory you will create a .groovy file for the function and a matching .txt file any documentation of the command you want to add. In our example let’s create a hello function.
Create a hello.groovy and a hello.txt file. Inside the hello.groovy file, add something similar to the following.
echo ‘Hello world!’
Go ahead and commit the hello.groovy file, don’t worry about the hello.txt file.
git add hello.groovy
git commit -m “Hello world example”
git push (You may need to set your upstream)
Obviously this function won’t do much. Once you have pushed the new function you should be able to view it in the dropdown of pipeline functions in the Jenkins build configuration screen.
NOTE: There is a nice little script testing plugin built in as part of the pipeline now called snippet-generator. If you want to test out small scripts on your Jenkins server first before committing and pushing any local changes you can try out your script first in Jenkins. To do this open up any of your Jenkins job configurations and then click the link that says “Pipeline syntax” towards the bottom of the page.
Here’s what the snippet generator looks like.
From the snippet-generator you can build out quite a bit of the functionality that you might want to use as part of your pipeline.
Configuring the job
There are a few different options for setting up Jenkins pipelines. The most common types are the Pipeline or the Multibranch Pipeline. The Pipeline implements all of the scripting capabilities that have been covered so that the power of the Groovy scripting language can be leveraged in the Jenkins job as well as things like application life cycles (via stages) which makes CI/CD much easier.
The Multibranch Pipeline augments the functionality of the Pipeline by adding in the ability to index branches from SCM so that different branches can be easily built and tested. The Multibranch Pipeline is especially useful for larger projects that have many developers and feature branches being worked on because each one of the branches can be tracked separately so developers don’t need to worry as much about overlapping with others work.
Taking the pipeline functionality one step further, it is possible to create a Jenkinsfile with all of the needed pipeline code inside of a repo that so that it can be built automatically. The Jenkinsfile basically is used as a blueprint used to describe the how and what of a project for its build process and can leverage any custom groovy functions that you have written that are on the Jenkins server.
Using a the combination of a GitHub webhook and a Jenkinsfile in a Git repo it is easy to automatically tell your Jenkins server to kick off a build every time a commit or PR happens in GitHub.
Let’s take a look at what an example Jenkinsfile might look like.
node {
stage ‘Checkout’
// Checkout logic goes here
stage ‘Build’
// Build logic goes here
stage ‘Test’
// Test logic goes here
stage ‘Deploy’
// Deploy logic goes here
}
This Jenkinsfile defines various “stages”, which will run through a set of functions described in each stage every time a commit has been pushed or a PR has been opened for a given project. One workflow, as shown above, is to segment the job into build, test, push and deploy stages. Different projects might require different stages so it is nice to have granular control of what the job is doing on a per repo basis.
Bonus: Github Webhooks
Configuring webhooks in GitHub is pretty easy as well. SCM is fairly standard these days for storing source code and there are a number of different Git management tools so the steps should be very similar if using a tool other than GitHub. Setting up a webhook in GitHub can be configured to trigger a Jenkins pipeline build when either a commit is pushed to a branch, like master, or a PR is created for a branch. The advantages of using webhooks should be pretty apparent, as builds are created automatically and can be configured to output their results to various different communication channels like email or Slack or a number of other chat tools. The webhooks are the last step in automating the new pipeline features.
If you haven’t already, you will need to enable the GitHub plugin (https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) in order to use the GitHub webhooks. No extra configuration should be needed out of the box after installing the plugin.
To configure the webhook, first make sure there is a Jenkinsfile in the root directory of the project. After the Jenkinsfile is in place you will need to set up the webhook. Navigate to the project settings that you would like to create a webhook for, select ‘Settings’ -> ‘Webhooks & services’ . From here there is a button to add a new webhook.
Change the Payload URL to point at the Jenkins server, update the Content type to application/x-www-form-urlencoded, and leave the secret section blank. All the other defaults should be fine.
After adding the webhook, create or update the associated job in Jenkins. Make sure the new job is configured as either a pipeline or multibranch pipeline type.
In the job configuration point Jenkins at the GitHub URL of the project.
Also make sure to select the build trigger to ‘Build when a change is pushed to GitHub’.
You may need to configure credentials if you are using private GitHub repos. This step can be done in Jenkins by navigating to ‘Manage Jenkins’ -> ‘Credentials’ -> ‘Global’. Then Choose ‘Add Credentials’ and select the SSH key used in conjunction with GitHub. After the credentials have been set up there should be an option when configuring jobs to use the SSH key to authenticate with GitHub.
Conclusion
Writing the Jenkinsfiles and custom libraries can take a little bit of time initially to get the hang of but are very powerful. If you already have experience writing Groovy, then writing these functions and files should be fairly straight forward.
The move towards pipelines brings about a number of nice features. First, you can keep track of your Jenkins job definition simply by adding a Jenkinsfile to a repo, so you get all of the nice benefits of history and version tracking and one central place to keep your build configurations. Because groovy is such a flexible language, pipelines give developers and engineers more options and creativity in terms of what their build jobs can do.
One gotcha of this process is that there isn’t a great workflow yet for working with the library functions, so there is a lot of trial and error to get custom functionality working correctly. One good way to debug is to set up a test job and watch for errors in the console output when you trigger a build for it. The combination of the snippet generator script tester though this process has become much easier.
Another thing that can be tricky is the Groovy sandbox. It is mostly and annoyance and I would not suggest turning it off, just be aware that it exists and often times needs to be worked around.
There are many more features and things that you can do with the Pipeline so I encourage readers to go out and explore some of the possibilities, the docs linked to above are a good place for exploring many of these features. As the pipeline matures, more and more plugins are adding the ability to be configured via the pipeline workflow, so if something isn’t possible right now it probably will be very soon.
