Categories
Computing

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.
Categories
Computing

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 https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm 
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
Categories
Computing

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 https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm 
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

Categories
Computing

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