REDtalks.live #24: Becoming Super-NetOps: Day 1

/ Nathan Pearce / Leave a comment

If you’re right at the beginning of your Super-NetOps journey, then this article is for you!

A common question from our NetOps pals is, “How do you get started?” Well, let me take a stab at that in todays article. Before we begin, a few things to keep in mind.

  1. EVERYONE is starting from a different level. Focusing on who’s ahead of you in the learning path will only distract you from your success. This journey is about you. Go at YOUR pace.
  2. Making mistakes is good. Mistakes are evidence that you are learning new things and have the confidence in yourself to evolve. Learn more about a great culture for innovation from John Allspaw, here. <- A good one to share with the team!
  3. Beyond the tools and scripts, pay close attention to how you change your approach to troubleshooting and moving forward with a solution. Often overlooked, learning to automate without adopting and nurturing new practices and culture is almost pointless. Take the time to see how process changes and how you begin to look at challenges differently.

Ok, keeping these points in mind, here’s some new concepts to look into:

1. Understand RESTful interfaces

If this is your first time venturing away from the GUI/CLI, or maybe you just want a refresh, I recommend you watch this great REST API introduction video posted by WebConcepts. In this video you’ll see how you can communicate with popular on-line services including Facebook, Google Maps, and Instagram via their REST APIs:

 

2. Interact with a RESTful Interface

There are many tutorials on the internet that show how to communicate with a RESTful interface from a scripting language, like Python or Javascript. But what if you don’t know the scripting languages they refer to? Sometimes its best to avoid an overload of too many new concepts to learn at once.

For this very reason, I tend to direct people to the awesome, multi-platform REST client, POSTMAN: https://www.getpostman.com/

While their messaging does target ‘API Development teams’, its fantastic for API beginners, too. With POSTMAN installed, I recommend you watch the great tutorial “How to use the POSTAN API Response Viewer”:

 

Once you’ve worked through the basics, I recommend going through the POSTMAN video tutorials to learn some of the time-saving features you’ll come to depend on: https://www.youtube.com/playlist?list=PLM-7VG-sgbtCJYpjQfmLCcJZ6Yd74oytQ

3. Troubleshooting JSON

Now that you’ve had some interaction with a RESTful interface, you’ve probably had some experience with how a small error can break things. Fear not, while you’re on your path to becoming JSON-fluent there’s always the great on-line JSON validator, https://jsonlint.com/

Simply ‘paste’ your misbehaving JSON data into the text field and click ‘Validate JSON’. Below its showing me that I missed a comma on the end of the second line:

JSONLint_-_The_JSON_Validator

We’ll look at more data formats, like YAML, in future posts.

4. Conclusion

If you’ve worked through these exercises then congratulations is in order. You have already begun your journey towards becoming a Super-NetOps engineer! If you’re still feeling a little overwhelmed with these concepts, there is no shame is working through them again from the beginning. Repetition builds expertise and being comfortable with change is all part of the journey!

Next in the series we’ll look at some more advanced POSTMAN features and then take what you’ve learned in POSTMAN and apply it to scripting languages.

 

REDtalks.live #23 – Aspen Mesh w/ Shawn Wormke

/ Nathan Pearce / 1 Comment

Want to learn about Service Mesh? Well, you’re in luck! Today I am joined by Shawn Wormke, Sr. Director of Aspen Mesh – aspenmesh.io – an F5 Networks Incubator innovation.

Aspen Mesh is an ‘enterprise service mesh’ built on Istio. In her recent blog, industry thought leader, Lori MacVittie (@lmacvittie), announced the drivers behind launching Aspen Mesh with:

“…we believe a robust microservice communication fabric is the best possible path to scaling containerized apps whether in the data center or in the cloud (or both). But we also understand the needs and complexity of enterprise production environments. A service-mesh needs to do more than just scale apps; it also needs to monitor and secure them.”

Watch this video to understand the future of Aspen Mesh: the microservices architecture its destined for, and the use cases it will address regarding the application of dynamic policy and service visibility through continuous feedback.

Thanks for joining us, Shawn!

REDtalks #22 – IBM Cloud with Simon Kofkin-Hansen

/ Nathan Pearce / Leave a comment

In this episode I’m joined by Simon Kofkin-Hansen of IBM Cloud.

As Distinguished Engineer of Cloud Automation, Simon travels the world enabling organizations a smooth transition towards their hybrid cloud goals. Watch this episode to understand some of the realities of a journey to cloud, what to look at for, and what you might want to do differently to make the most out of your newly adopted operating model. HINT: automation is key!

Thanks for joining us, Simon! Great to have you on REDtalks.live

REDtalks #21 – Super-NetOps Live Q&A

/ Nathan Pearce / Leave a comment

UPDATE: incase you missed it, see a recording of the “What is Super-NetOps Live Q&A” here: https://youtu.be/qFbmiVrvxlE

On October 24th, at 9am PST (UTC -7) we will be hosting a Live Q&A forum on Super-NetOps (NetOps for DevOps) – click on the video below for details, or open directly on YouTube here.

Whether you’re a total beginner to infrastructure automation, or well on your way with Programmable Infrastructure, bring your questions for our Super-NetOps champions to answer. Simply enter your question into the ‘live chat’ window now, or during the live broadcast.

For some background, we’ve covered Super-NetOps in previous articles including Does DevOps need a “Super-NetOps”? and REDtalks #19 – Super-NetOps Explained. Due to the overwhelming interest we’re hosting this Live Q&A session to help accelerate your journey.

Live Q&A will commence October 24th, 9am PST (UTC -7).

 

REDtalks #20 – Programmable Infrastructure 101 – be Declarative

/ Nathan Pearce / Leave a comment

While the payoff of a successful implementation can be HUGE, the beginning of your Programmable Infrastructure journey may be difficult and fraught with danger. There are decisions you need to make right from the start that will dictate the experience you and your customers, external or internal, encounter. To avoid ‘kicking an operational nightmare can further down the road’ (or into the orchestrator as it may be), ensure you are employing declarative API interfaces and appropriate levels of abstraction in your automation tooling.

In this episode I explain the importance of declarative API interfaces. Trying to move all of the knobs and buttons of programmable infrastructure into your deployment tooling WILL come back to bight you later. It will be costly to support, it will create an integration too rigid to adapt to new systems and services, and it will increasingly inhibit business agility as time goes on.

 

Thanks for joining us on the 20th episode of REDtalks.live

REDtalks #19 – Super-NetOps Explained

/ Nathan Pearce / 2 Comments

Due to popular demand, here is a short (16 minute) video explanation of the Super-NetOps persona.

I frequently give talks on the need for Super-NetOps engineers and architects to support modern development/DevOps processes. However, that talk (especially with enthusiastic Q&A sessions) takes about 90 minutes. Hence, below is a quick ‘why you need Super-NetOps’ version I put together for those in a hurry.

Brilliantly summarized by my colleague, Joe Cassidy, “Great short video by Nathan Pearce explaining the “Super-NetOps” concept wherein NetOps embraces principles and practices of DevOps to reduce the skills gap between Infrastructure and Developer silos. Like DevOps, “Super-NetOps” is not a technology, tool or person but rather a culture change where infrastructure teams adopt “systems thinking”. This shifting focus towards “systems thinking” empowers the traditional infrastructure silos to collaborate, continuously improve delivery, enhance communication, enable self-service and speed development. F5 is helping enterprises embrace this concept by (among other things) enabling APIs, exposing Declarative Interfaces and executing on Self-Service Models and Templates.”

Thanks for listening!

https://f5.com/supernetops

 

REDtalks #18 – Enabling the docker TCP API in AWS

/ Nathan Pearce / Leave a comment

Not a traditional REDtalks post today (no interview/demo), but this took me a while to work out so I thought I’d share.

What’s this about?

It all started with me building REST extensibility solutions for F5 Networks in AWS. I created (Launched) a new AWS AMI Linux instance – yep, the very first one on the list: “Amazon Linux AMI 2017.03.0 (HVM), SSD Volume Type“.

Next, I followed the AWS instructions to install docker:

sudo yum update -y

sudo yum install -y docker

sudo service docker start

sudo usermod -a -G docker ec2-user

docker info

NOTE: Full docs here: http://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html

This is where I got stuck!

As part of the solution I needed to issue a docker command on the docker host, from inside a container… Ok, Batman, to the Google-copter…

There’s loads of suggestions out there to map /var/run/docker.sock into the container using -v. For example:

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock my_container sh

With this you can execute:

$ curl --unix-socket /var/run/docker.sock http:/containers/json

HOWEVER, there are loads of forum posts saying to be real careful about mapping /var/run/docker.sock to all you containers…

What to do?

Enable the API over TCP! 

Back to the Google-copter, there are a few posts out there about getting it running on Ubuntu but none for the Linux AMI distro…

A solution (hours later…)

1. Change some startup options:

The default ‘OPTIONS’ in /etc/init.d/docker is:

OPTIONS="${OPTIONS:-${other_args}}"

we need to change this to:

OPTIONS="${OPTIONS:-${other_args}} -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

So, you need to go ahead and edit that to something link this:

$ sudo vi /etc/init.d/docker

#OPTIONS="${OPTIONS:-${other_args}}"
OPTIONS="${OPTIONS:-${other_args}} -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

2. Restart docker for these options to take effect:

sudo service docker restart

Now you have enabled the docker API over TCP! #w00t

Test the API

Lets get the API version:

curl http://<ip_address>:2375/version

NOTE: Replace <ip_address> with the IP address of the docker host, or its hostname!

The response will look something like this:

{"Version":"1.12.6","ApiVersion":"1.24","GitCommit":"7392c3b/1.12.6","GoVersion":"go1.6.3","Os":"linux","Arch":"amd64","KernelVersion":"4.9.20-11.31.amzn1.x86_64","BuildTime":"2017-03-07T20:34:04.601909006+00:00"}

Note the:

"ApiVersion":"1.24"

Now add that version number to the beginning of the URI, slap json on the end of it, and presto:

curl http://<ip_address>:2375/v1.24/images/json

Returns:

[{"Id":"sha256:80ee3a0f225e543668eca9922bf5642bce0e484403df665f3ac9b107d2895d40","ParentId":"","RepoTags":["npearce/ilxe-festivus:latest"],"RepoDigests":["npearce/ilxe-festivus@sha256:973dbf813f6a7f07929b8fd86da4fa9b79f613228e3942fb35d9d525fcfa61b0"],"Created":1495771390,"Size":85001082,"VirtualSize":85001082,"Labels":{}}]

 

Now you can go read this: https://docs.docker.com/engine/api/v1.24/

Enjoy!

CAUTION: One last step, and this is REALLY important! Don’t leave your Docker API open on the Internet!

REDtalks #17 – Orchestration 2.0 (w/ a side of bacon)

/ Nathan Pearce / Leave a comment

Greeting automators and welcome to edisode #17 of REDtalks. Today’s guest is Tyler Hatton who is from WWTs own internal IT Operations team. Tyler is the F5 BIG-IP Subject Matter Expert for WWT and is hell-bent on replacing the mundane with declarative interfaces and orchestration systems.

Watch this episode to hear about the interesting culture at WWT and their regular hack-a-thon’s. These events themed at breaking the routine and investing internally in continuous education and, my favorite, “continuous improvement”. Following this, Hatton talks us through his brilliantly named, hack-a-thon winning, “(P)orchestrator” solution!

Tune it to understand the time-saving, self-service interface that Tyler produced, quite literally, from the Ops ‘drivers seat’.

 

Many thanks, Tyler, for sharing your story!

Thomas A. McGonagle – REDtalks.live Author

/ mcgonaglethomas / Leave a comment

Hello,

My name is Thomas (Tom) A. McGonagle http://www.linkedin.com/in/thomasmcgonagle, and I am a new REDtalks.live author. You might recognize me from previous REDtalks #16 and #14. I am a new Senior Product Management Engineer working on F5’s Programmability and DevOps. I am a former Field Systems Engineer based out of Boston, MA. Where I have lived my whole life, and over the last 10 years been devoted to the DevOps movement.

I have been a customer facing engineer my whole career. I was a DevOps strategy consultant at Booz Allen Hamilton and CloudBees the makers of Jenkins. I was a customer facing Site Reliability Engineer at RedHat, and I owned my own Puppet consulting business for three years. At Cloudbees, I had a blog called Field Notes from a DevOps Cultural Anthropologist. One of my favorite blogs, was a blog on Buddhism and DevOps https://www.cloudbees.com/blog/bramavihara-four-immeasurables-devops

In addition to my work, I also spend a lot of time working with the DevOps community. I am the organizer of the Boston Jenkins Area Meetup group, which is the largest Jenkins meetup in the world as well as HackerNest the tech social meetup group. I am also active and help with the Boston DevOps meetup group and the F5 user’s meetup group. DevOps community organizing is a passion of mine.

Its an honor and a privilege to be an author on REDtalks.live, I am both impressed and passionate about the message and content that Nathan has been able to create. My greatest professional goal is to get NetOps engineers practicing Agile and DevOps. I have been calling this Agile Networking, but we at F5 are coalescing around calling it Super NetOps.

My version of CAMS (Culture, Automation, Monitoring and Sharing) is ACAMS+ (Agile, Culture, Automation, Monitoring, Sharing, PLUS whatever is important to the customer, i.e., Network and Security). I find CAMS and ACAMS+ to be great frameworks for discussing DevOps. They are the core values of DevOps, but not its DNA. Cracking the DNA of DevOps requires a singular focus on teamwork and team mission.

The DNA of DevOps is as follows:

  • Team of coordinated specialists
  • Oriented to a common goal
  • Servant leader providing coordination and communication
  • Empathetic in dealings with others
  • Trust in the rest of the team
  • Dedication to the common goal
  • Selflessness, adherence to the greater good
  • Determination and resiliency in the face of difficulty
  • Honesty with the leader and the rest of the team
  • Commitment to the mission

REDtalks #16 – Andy & Tom on Metrics Driven Automation

/ Nathan Pearce / Leave a comment

In episode #16 we are joined by Andreas (Andy) Grabner, of Dynatrace, and Tom McGonagle, of F5 Networks.

Watch this episode to hear about Metrics Driven Automation, or Informed Automation, and how this takes the feat out of fully integrated deployment pipelines. Andy shares some great insights on how to avoid automating oneself into dangerous situations.

Following this, Tom shows us (yes, a live demo) how to deploy an F5 BIG-IP policy using the CI/CD tool, Jenkins.

 

You may recall Tom from a previous episode, REDtalks #14 – Tom & David on the Principles & Practices of DevOps. Thanks for coming back, Tom! Here’s the Jenkins Github repo he referenced in his demo: https://github.com/mcgonagle/F5file

And thanks, Andy, for your valuable insights on  impelmenting safe, information automation. Andreas To hear more from Andy Grabner, take a look at some of these links:

Thanks, both, for your time!