Visual Studio Code Remote Development Setup

Instructions for setting up VS Code to remote to a Linux server.

In my case, it’s Amazon Linux 2 running .net core. In Linux, at the command line, I created a project using:

dotnet new web --name Employee

Then on VS Code (running in Azure), connect to the Amazon Linux instance by:

  1. Install the Extension Pack Remote-SSH.
  2. Verify that you can ssh to the remote server using Powershell or GitBash (or another tool of choice).
  3. In the leftmost pane of Visual Studio Code, click on the Remote Explorer icon.
  4. In the SSH Targets explorer, click the Configure icon. (It looks like a gear.)
  5. In the middle of Visual Studio Code, you’ll see a prompt with several possible files. Choose whichever you prefer.
  6. Fill in the values for your setup similar to the following:
  1. In VS Code now, near the bottom left, you should see “SSH:Hostname” where Hostname is the name of the Host in config. Navigate to the desired folder to open your project.

Spinning Up .NET Core on CentOS 8

Simple steps to get going.

  1. Create the Amazon Linux Instance via the Console, CloudFormation or the CLI.
  2. Log in to the instance using SSH or EC2 Instance Connect (browser).
  3. Run the following:
sudo dnf upgrade -y
sudo dnf install git -y
sudo rpm -Uvh 
sudo yum install dotnet-sdk-3.1 -y

# optionally test the installation
cd ~
mkdir -p projects/hello && cd projects/hello
dotnet new console
dotnet run

# optionally remove the directory
cd ~
rm -rf projects

Spinning Up .NET Core on Amazon Linux

Simple steps to get going.

  1. Create the Amazon Linux Instance via the Console, CloudFormation or the CLI.
  2. Log in to the instance using SSH or EC2 Instance Connect (browser).
  3. Run the following:
sudo yum upgrade -y
sudo yum install git -y
sudo rpm -Uvh 
sudo yum install dotnet-sdk-3.1 -y

# optionally test the installation
cd ~
mkdir -p projects/hello && cd projects/hello
dotnet new console
dotnet run

# optionally remove the directory
cd ~
rm -rf projects

Photo by Luca Campioni on Unsplash


A Note on Connecting GitHub Webhooks with Jenkins in AWS

Jenkins is a potential CI/CD solution for my company. I’ll admit that I have it in for Azure DevOps. No one really understands it well. The person who set it up has left the company. Jenkins is likely the leader in this space.

As part of this effort, I wanted to explore GitHub Webhooks as automatic triggers for builds in Jenkins.

There are many excellent resources online for helping with setting up that Integration. Here is one. Many resources appropriately assume connectivity between a Git repo and Jenkins. That connectivity is not necessarily a given so I thought to share some issues I ran into with connectivity between my personal public GitHub repo and Jenkins box on AWS.

Using a public repo does simplify the GitHub side of the equation. In my case for the AWS side, the Jenkins server has an elastic IP that is protected by a Security Group. Only traffic originating from specific IPs is allowed, so one needs to find a way to accept only those packets that belong! The rub here is that we want to allow the traffic coming from GitHub, which was denied by design.

GitHub actually makes this fairly easy by publishing their IPs here. It simply became a matter of setting up (in my case) a dedicated Security Group to stipulate the IPs. GitHub also makes it fairly easy in the UI to test delivery and redelivery of Webhooks on the Webhooks page.

As you can see from the image above, one simply needs to click on the redelivery button to understand whether connectivity was achieved. In my case, I kept increasing restrictions in the Security Group and re-testing delivery noting the successful connection.

Sidenote – Binding GitHub and Jenkins

One interesting configuration item of note is that GitHub Webhooks point to a Jenkins server followed by /github-webhook/. They do not point directly to the URL of the Jenkins Project that will do the build. Note the Payload URL below.

In Jenkins, you do stipulate the repo to which the Project will be bound as shown below. (Those two are shown below. )There is additional configuration needed in Jenkins, but that’s beyond the scope of this article and may be found here.

Photo by Edson Rosas on Unsplash


Keybinding Gnome Screenshot

There’s a nice little program for taking screenshots available for Windows and Mac called Greenshot. It’s keybound on my Windows installation with Ctrl+Alt+P.

Greenshot isn’t available on Linux. Wanting to have a consistent experience between machines with Linux’ gnome-screenshot, it was fairly easy to bind that program the same way in Linux.

  1. Launch Settings. You can search for it by pressing the Super key.
  2. In Settings, go to Devices >> Displays >> Keyboard.
  3. Scroll to the very bottom. Click the “+”.
  4. In the Set Custom Shortcut screen, set the Name, Command and Shortcut as shown below. Note that the -ia flag sets the program to start interactively and defaulted to area selection respectively.

You can review the available flags using man.

Photo by Daniel Korpai on Unsplash



A graphic for the Amazon documentation “How Amazon Elastic Block Store (Amazon EBS) Uses AWS KMS“.

EBS, EC2 and KMS (1)


A Case for Automation

andy-kelly-402111-unsplashI sat on several calls today — on a day off, no less. Sigh.

We shouldn’t really even need to be making a case for automated deployments, but unfortunately I find myself (still) doing so regularly.

Today was to be spent studying for an AWS exam and doing some other productive things. Like most other responsible professionals, I don’t mind hopping on a quick call or two on a day off — in fact, I like it. It makes Monday (today is Friday) a little easier.

But today was not to be spent studying.

The first call (2 hours) was spent trying to understand why a web deployment to a production server had gone awry. Most articles on 502 errors begin by explaining that the error is hard to track down. No amount of checking the Application log seemed to help.

Dev and QA work without issue. Production appears to match in as much as I’m allowed to see. These issues occur often enough that I left several days wiggle room prior to the release. So, luckily, we have 5 days to figure things out.

On the second call, a developer on my team and I watched the SysAdmin deploy several SSIS packages. There are not only packages involved, but of course T-SQL powering those packages, shares that need to be setup, SQL Jobs, etc.

The Admin was doing a remarkable job with excellent attention to detail. He was also logging everything he was doing with screenshots and notes.

Still on one occasion, I asked him to check one of the shares he created where he added permissions to the share, but not to the folder. A missed step.

I asked him to check several additional things. Each of those was done perfectly.

A few minutes later, I remarked to the developer that one of the new Integrations wasn’t appearing on our dashboard. The script to create the database entry was missing, so the developer created it on the fly and amended our instructions. The Integration still didn’t appear. The amended script had a copy-paste error in it and still hadn’t created the correct database entry for the new integration.

We follow a fairly typical deployment pattern.

  1. It works on the developer’s machine.
  2. It works in a development environment.
  3. It works in a QA environment (servers, databases, etc) that the developer cannot access. It’s deployed to QA by the same SysAdmin who deploys to Production. A tester tests in both DEV and QA. Automated tests, where appropriate, occur.
  4. It gets deployed to Production.

The second call, observing the Production deployment, took over an hour.

The problem is not the people, at least not these two people working on the deployment. They’re both remarkably competent professionals. They have great attention to detail. They were both calm, reserved and professional the entire time.

The problem is with the process and the inability or willingness to move away from this archaic process. What’s worse is the stress that accompanies these deployments. One tiny mistake can cause an entire process to fail.

For us, this can be a failure to transmit financial information in a timely or correct fashion.

What’s needed, of course, is the ability to perform hundreds or even thousands of test deployments against identical environments. Ideally, identical environments, automated deployments, automated test scripts, then tearing the whole thing down, and going again. Inserting planned failure in the process to observe a successful rollback and notification.


Not entirely without coincidence, I had a slide deck open on another machine from a CloudFormation presentation given at a Chicago AWS Group that I was unable to attend.

Of course, CloudFormation and SSIS deployments aren’t really the same animal, but conceptually, the ability to automate infrastructure and the ability to automate application deployment aren’t terribly different.


I’ve been pushing the issue lately. Today’s deployment took a combined team time of 10 hours. Most pieces deployed fine in the end, but the single piece that didn’t means that what did get deployed can’t yet be used.

The team is hundreds of hours into the effort to modernize this process. More modern security, a better UI, regression testing over 800 files (all we had) and coordination for the rollout are all potentially delayed. That’s to say nothing of the time we all should have spent doing more productive things.

There is one thing holding us up from modernizing and that is an inability or unwillingness to improve this process.

But not for much longer.

Photo by Andy Kelly on Unsplash


Create an EC2 Instance from a Snapshot

A Use Case for this is when you have a dedicated instance that you’d like to reuse for another purpose.

There is a quicker way to clone an instance when using on-demand instances. That is by creating and using an AMI.

  • Prior to Setup
    • Determine the Availability Zone you want to use.
    • Note the Security Group of the existing EC2 instance.
  • Create a Snapshot from the instance you wish to clone.
    • On the EC2 Dashboard, navigate to Elastic Block Store >> Volumes.
    • Identify the Instance you wish to clone in the Attachment Information column.
    • Actions >> Create Snapshot
  • Create a Volume from the Snapshot.
    • On the EC2 Dashboard, navigate to Elastic Block Store >> Snapshots.
    • Identify the Snapshot from which you wish to create a Volume.
    • Actions >> Create Volume
    • IMPORTANT!: Choose the desired Availability Zone.
    • Note the Volume Id.
  • Create an EC2 Instance in the desired Availability Zone.
    • Choose the same Security Group as the modeled instance.
    • Follow the steps in the Wizard.
    • Once the Instance has started, stop the instance.
  • Force Detach the existing Volume from the Instance.
    • On the EC2 Dashboard, navigate to Elastic Block Store >> Volumes.
    • Actions >> Force Detach
    • Optional but recommended. Actions >> Delete
  • Attach the cloned Volume.
    • On the EC2 Dashboard, navigate to Elastic Block Store >> Volumes.
    • Actions >> Attach
    • Choose the desired instance and specify the Device.
  • Start the EC2 Instance.
    • On the EC2 Dashboard, navigate to Instances >>Instances.
    • Actions >> Instance State >> Start

Screen Shot 2018-09-15 at 7.03.20 AM

Feature Photo by Robin Spielmann on Unsplash


Auto Scaling Metrics: A Brief Overview


While studying for the AWS Solutions Architect Professional exam, I wanted to memorize the Auto Scaling Metrics. It was suggested that knowing these metrics cold would be helpful on the exam.

During a review, it became obvious that for Auto Scaling metrics, there were three broad categories of Size, Capacity, and Instances. Each Category could be further explained by some Detail.

Metric Category Detail
GroupMinSize Size Min
GroupMaxSize Size Max
GroupDesiredCapacity Capacity Desired
GroupInServiceInstances Instances Desired
GroupPendingInstances Instances Desired
GroupStandbyInstances Instances Desired
GroupTerminatingInstances Instances Desired
GroupTotalInstances Instances Desired

For the Instances Category, there are some interesting distinctions to be made among the set. InService discludes pending and terminating. Total includes InServicePending and TerminatingStandby includes instances running, but not InService.

Recall from Lifecycle Hooks the general states for an EC2 instance:

Pending –> InService –>Terminating.

If we then order the metrics: GroupPendingInstances, GroupInServiceInstance and GroupTerminatingInstances, we can then easily add the remaining Total and Standby metrics for overall clarity.

Photo by Chris Liverani on Unsplash


Muster 005 DC: Experience

Most photos from Jocko’s Twitter feed

If you don’t know who Jocko Willinck is, here’s the synopsis. Born and raised in New England. Dreamt of being a commando (his words). Became one as a Navy Seal. Fought in Ramadi, Iraq in 2006 in what is known as the Battle of Ramadi where fighting was considered to be the worst.

Helped turn around that city. A report cited by the Washington Post, known as the Devlin Report, stated that the city was essentially lost.

Jocko is highly respected for his leadership style which he distilled for the SEALs upon his return from Ramadi. He served as the Officer-in-Charge of training for all West Coast Seal Teams. Has a number of books on leadership, books for young people. Well-known for his podcast. (There are links at the end of this post to help you find free and paid materials.)

Jocko assembled a team of military leaders as consulting firm (Echelon Front) to train non-military about leadership concepts.

The answers to questions regarding leadership apply across race, gender or any other difference you may want to consider.

This article is NOT about the concepts discussed at the Muster. Those concepts are easily found in Jocko’s podcast, his books, and his Twitter feed. Many are free. Musters are not free, but I recommend them highly for a deep dive.

One interesting thing I came across is that a number of people who were there that self-funded the conference. Companies perhaps don’t get it. Jocko and team are quick to point out that you may want to apply what’s learned and not necessarily mention the military antecedent. Having those ties might create unnecessary resistance — the goal is effective leadership, not an advertisement for Echelon Front or Jocko.

This article IS about the actual Muster experience. That’s something you might not necessarily get elsewhere.

Day 1 PT

At 4:25, I leave my hotel room to head to morning PT, optionally offered to all attendees. I don’t particularly do well getting up and “getting after it” as Jocko would say, so I rise at 3:30, make some hotel room coffee and grab a quick shower. At 4:30 am, I head down. In the tunnel connecting the hotel to the adjacent underground mall, there are already 200-300 waiting to go do burpees, jump squats, push-ups, flutter kicks, arm-somethings, and sit-ups. (In the picture below, note the picture of Jocko lined up with ready and willing participants.) By the time we head out, 400 people are lined up. The rain is “no factor”. The workout starts at 4:45 am. Each set is two minutes. You get 30 seconds of rest in between each set. Rest means you do jumping jacks. Do that twice. At least one person who looked to be in great shape was puking afterward.


Then Jocko mentions that there were 14 officers killed last month in the US. 400 people do 14 burpees.

Essentially 30 minutes of constant work, plus burpees.

OK. Now you’re done.

Don’t let that scare you off. People of every age, size, and sex were represented and did well.

Maybe you’re better than you thought. You just needed someone to point it out to you.

400 people walk back to the hotel greeting early-morning dog owners. I’m not sure they knew what to make of us.

Day 1 Morning

The doors to the conference open at 7:45 am leading to the large hall filled with video screens and conference room tables. Waiting for you are two booklets with much of the conference content. I brought my own small notebook and recommend doing so. I made quite a few notes and starred those things that I need to work on.

I sat next to a gentleman and struck up a conversation.

Me: What do you do for a living?

Him: (I’m paraphrasing and summarizing.) I’m a director for a company that supports organ transplants and donations. We match those who can donate organs with those in need. It’s an extremely time-sensitive effort, as you can imagine. I’m here to better learn how to support my team.

This is the type of story you’ll hear from people at this conference. Some of these people do incredibly important work. Everyone is highly motivated to lead better. I didn’t speak to one person who said they came because this was a track to a promotion. Every single person seemed driven to lead more effectively. Absolutely driven.

The morning is incredible, as you might imagine. We’re introduced or re-introduced to the Four Laws of Combat. The real-life combat scenarios and the ensuing lessons learned by Jocko and his team are covered. These are not your typical business scenarios. These are life-and-death situations where there’s not always a happy ending. This is NOT a feel-good conference. Despite the outcome, there is always a lesson learned. That lesson is always applicable to other scenarios. The lessons are sobering because of the loss of human life, people denied basic decency and the oppression of a population.

This video introducing the 2016 Muster from two years back gives you a good impression of what to expect.

Day 1 Lunch

The food at The Muster was meant for athletes. So, not your typical conference food. There is plenty of protein (steak and chicken); there are plenty of greens (4 kinds of lettuce, plus healthy toppings). You can find some healthy carbs too. The one table I saw with slices of cake seemed to be basically untouched.

There was an interesting conversation going on at my lunch table. These tables seat around 10-12 persons and were covered in white tablecloths. One of the gentlemen at my table was, based on his shirt and conversation, clearly helping to run the conference.

He mentioned in no uncertain terms that this is one of his favorite conferences. That was due not only to the subject, the presenters but also because of the attendees.

“Everything starts on time. Everyone is extraordinarily courteous to my staff. Jocko knows what he wants and asks for it.”

It’s true. Given other conferences I’ve attended, there is a noticeably different vibe to this conference. People are very courteous. People line up early to get in hoping to get a great seat; there isn’t any cutting in front of others or pushing. Everyone is extremely polite.

Attendees would line up during breaks to get their books personalized by Jocko and Leif. Jocko and Leif would pose with the attendees for quick photos. Near the end of a break, the lines were not quite exhausted. A staff member would inform those still in line that they would need to try again later. No complaining or whining. People get it.

Jocko and Leif also tirelessly spend time meeting with those who have a great interest in this subject. It didn’t seem like they were taking any breaks.


I mention to my wife that this seems to be a conference of biceps and tattoos. As is my experience in other areas of my life, these are among the most well-behaved people walking around.

Day 2 PT

Day 2 PT was easier. Well, until the next day.

AMRAPs. 20 minutes. Lunges, push-ups, squats, sit-ups. Do as many sets of 10 as you can. I got through 10 plus sets in 20 minutes and had started 11. So, 100 of everything. That was my goal, but certainly less than what was being encouraged. (The goal was 1 set per minute.)

Before beginning, Leif Babin announced that there was one “puker” yesterday.

He’s hoping for three today.

No one takes offense at this, or should. If you’ve ever pushed your limits, puking is certainly possible.

The team of SEALs is walking around encouraging people and joking with those they know to be ex-military.


A bunch of out-of-shape business people (even in this crowd) get just what they need to challenge themselves. And they do. The gentleman next to me appears to be in his early 60s. No factor. The young lady in her 20s next to me is excited afterward to tell me that she did 10 sets and didn’t think she could ever do 100 push-ups.

As we’re exercising, in the background I hear, “that’s not a rep, Marine. One. One. One.” Clearly, he’s talking to someone he knows to be military. It’s all good-natured.

The rain I feel is truly a gift. I remove my cap after a few sets since I’m sweating quite a lot even with the temperature in the mid-60s. The cool rain feels great — any thought of getting drenched is replaced by gratitude for the light rain.

So, I’m feeling pretty good about the 20-minute workout, my pace and being able to finish strong. We practice finishing strong in Muay Thai and my last set of push-ups is no problem.

We approach the stand. Leif comments that we’re going to do “one more thing” and it begins with a “B”. Someone chimes up “burpees?”.

“Nope. We’re going to bear crawl across the soccer field.” Thankfully, he means across, not lengthwise. That means, assuming a conventional soccer field, we’re likely to bear crawl half of a football field. (Bear crawls happen to be one of my least favorite things.) I get behind some folks who occasionally drop to their knees and stop. For this, I am grateful. I make it across and watch those behind me finish.

There is one gentleman making his way across the field after all have finished. He is struggling but persisting. Someone (presumably from Jocko’s team) runs out on the field not to yell, but to encourage. That team member drops down next to our final athlete and does the bear crawl with him. All of us on the sidelines are cheering and clapping. We’ve all been there — normally without 400 others looking on. As this person crosses the sideline, he’s greeted generously by a host of people.

Each day, the walk to PT is interesting. Nothing about walking, but everything about people. I try to strike up a conversation both ways and doing so is really easy.

On the way to PT on Day 2, I spoke to a firefighter from Maryland. He’s a young officer, with a six-year-old child who does jiu-jitsu and loves it. This officer, like me, is there on his own dime and is quite grateful for the discount Echelon Front offers him (as a first responder, deeper than my early bird discount, as it should be). He gets how important all of this is and like everyone there is motivated to be a better leader. He looks like a bit of a bad-ass, but as I discover from our conversation, he’s really friendly and a little shy.

On the way back, I chatted with someone running training programs professionally. In contrast to the firefighter, his company has embraced Extreme Ownership to the point where they’ve purchased books for their staff and are sending him to check out the program to determine if others from his company should go. And oh, by the way, he is former military, was in Afghanistan during the late 2000s and trained bomb dogs.

When I tell people what I do, they don’t typically get it. “I work for a Real Estate Investment Trust supporting their technology efforts”. I always feel a bit embarrassed. Here you are saving lives and well, I do this thing where we just try to provide a great place to live and make money for our shareholders.

As I learn later in the conference, Jocko and team don’t necessarily see what you do as a reason for embarrassment.

At the end of the conference, they refer to the economic power of the United States as critically important. They don’t see themselves as better, and they don’t necessarily see others as lesser. The power of the economy in the world is strong a necessary for influencing freedom.

While I was walking with my bomb-dog friend, we happened behind Rob Jones. If you don’t know who Rob Jones is, check out his site. More reason to be humbled. Mr. Jones served as a Marine Corp combat engineer and lost his legs. Like the rest of us, he went to the morning AMRAP workout (lunges, push-ups, squats, and sit-ups in sets of ten, as many sets as possible for 20 minutes.) Except he has prosthetic legs.


This makes me realize how really lazy, whiny and self-centered most of us are. As we’re walking, I realized Mr. Jones was chatting with Dave Berke who is a real-life Top Gun; he was a Top Gun instructor and is a member of the Echelon Front team. (The attendees kidded Mr. Berke during his presentation on Thursday that he was the real Maverick from the movie Top Gun.) In addition to being an instructor at Top Gun, he found time to get a Master’s from Johns Hopkins School of Advanced International Studies with a concentration in Strategic Studies.

What you might get out of the conference

In addition to the two days at the conference, I spent my short flight home (1.5 hours) and much of the next day reflecting on areas where I can make improvements with my team.

As mentioned earlier, this is not a feel-good conference. You’re asked to consider how you can improve as a leader in light of the lessons learned by Navy SEALs. Everyone walks away with ideas for their improvement. Certainly, that’s why you would attend.

Concepts that I have applied have worked remarkably well. In fact, on a recent project, there was a lot of excitement surrounding the project itself where these Extreme Ownership principles were applied.

In the least, what you’re likely to walk away with are two provided notebooks summarizing the conference ideas. If you take notes yourself, you’ll also have plenty of items to go back and consider. It’s likely weeks or months of incremental improvements you can make for yourself and your team.



Jocko Podcast

Jocko Podcast on YouTube

Jocko Podcast “Good”

Jocko Podcast “Sisyphus”

Echelon Front


Jocko’s Amazon Page