DEV Community: Bruce MacKenzie

Managing Multiple Git Accounts on a single machine

Bruce MacKenzie — Sat, 15 Jul 2023 18:44:19 +0000

Introduction

Suppose you want to work with git repositories whose remotes are authenticated with different user accounts. Maybe you have work and personal GitHub accounts, or you work with repositories from multiple hosting services like GitLab or Sourcehut.

The simplest solution is to clone the repositories using HTTPS (instead of SSH). But who wants to enter a username and password for every authenticated command? This post will demonstrate an SSH-based configuration for seamless operations.

Ready? Let's get into it.

Prerequisites

Your remote git accounts (e.g. with GitHub or GitLab) are configured for SSH authentication, and your machine is configured for SSH authentication with one of these accounts.

If not, refer to GitHub's website for setup instructions, or the instructions provided by the hosting service of your choice.

SSH Key Setup

SSH keys are stored in ~/.ssh/ as public/private key pairs. By default the files are named after the encryption algorithm; for RSA you will find:

id_rsa
id_rsa.pub

or for ed25519:

id_ed25519
id_ed25519.pub

Copy the second pair of keys you wish to authenticate with to ~/.ssh/. Give them a unique name to set them apart from the first pair, e.g.:

id_rsa -> id_rsa_gitlab
id_rsa.pub -> id_rsa_gitlab.pub

Set correct file permissions for private and public key files:

chmod 600 id_rsa_gitlab # only owner can read/write
chmod 644 id_rsa_gitlab.pub # owner can read/write, everyone else can read

Git Configuration at Repository Level

This setup is the simplest method.

git config core.sshCommand "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa_gitlab -F /dev/null"

If you only require alternate authentication with a few repositories, this may be good enough. But if you want a single configuration that works across all repos in your user environment, continue reading below.

SSH Config Entry

To make this work with a single configuration in your user environment, we will use the SSH config.

Make SSH aware of the additional keys by editing ~/.ssh/config.

If the file doesn't exist create it first:

touch ~/.ssh/config
chmod 600 ~/.ssh/config

Add Host entries to the file:

# GitHub account
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa

# GitLab account
Host gitlab.com
HostName gitlab.com
User git
IdentityFile ~/.ssh/id_rsa_gitlab

When performing SSH authentication, the correct keys are determined by matching the config entry with the user and host names in the repository's remote URL.

To confirm an existing repository is configured to use SSH check the remote origin URL:

git remote -v

To change the remote URL run the command:

git remote set-url origin git@github.com:<user>/<repository>.git

To do this with a new repository clone with the SSH - not HTTPS - URL:

git clone git@github.com:<user>/<repository>.git

For example:

git clone git@github.com:bruc3mackenzi3/go-microservice-template.git

Entries for the Same Host

The example above will not work if both accounts are with the same host. For this a host alias is required:

# Work GitHub account
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa

# Personal GitHub account
Host github.com_personal
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa

github.com_personal is just an alias, anything will work here.

Now, with one of the commands provided above, clone or edit the remote origin URL to use the alias. E.g.:

git@github.com_personal:bruc3mackenzi3/go-microservice-template.git

Optional - Configure User Name and Email

It's also a good idea to set the user name and email for the repository. Even though this isn't used in the authentication process, this information shows up in commits and is used by GitHub to associate with a user account. Since you're reading this article, chances are your global Git configuration is set to another account.

Before changing, you can check the current value by running:

git config user.email

To set a different email:

git config user.email <your-github-account-email>

Note this sets user.email in the repository configration file, .git/config. If you saw a different email prior, chances are it was set in the global configuration and is still present. It is this email that will continue to be used in other repositories, unless they also overwrite the global user.email value with their own configuration.

You can confirm this by getting all values for an option:

git config --get-all user.email

Repeat the same for username with the same commands, by replacing user.email with user.name

Verifying the configuration works To verify the setup is working, we need to perform a git operation that requires priveledged access to a repository. If you went with the cloning option in section #3, and that repo is private then you've already confirmed it's working! Another way to verify is by pushing a new branch:

git checkout -b test-ssh-config
git push --set-upstream origin test-ssh-config

Conclusion

To explore this topic further, you can check out GitHub documentation on managing multiple accounts.

Thank you for checking out this post on improving development workflows with git repositories from different user accounts. I hope you find this configuration handy in creating a more seamless development experience. Happy git push'ing!

Developing and Deploying Microservices with Go

Bruce MacKenzie — Sun, 08 Jan 2023 17:27:16 +0000

Introduction

Entire books have been written on the subject of microservices. This post will scratch the surface by exploring the key ingredients that go into development and deployment of microservices. A demo microservice app will be used as a case study, presenting popular technologies to bring the concept into motion.

Go is a popular language of choice for modern, service-based architectures. The term cloud native is often used to describe Go, but what does it mean?

Go is a compiled language, meaning a Go program can be run on a target machine without the installation of dependencies. A higher level language by comparison, like Java or Python, requires its runtime environment and all 3rd party dependencies be installed. This has a number of drawbacks:

Added complexity to the build process
Built images have larger file size
CICD pipelines, image builds, cloud deployments, etc all take longer to run
All dependencies must be installed on target machines

A modern, compiled language like Go on the other hand has such advantages:

Dependencies are only required on the build machine
A single, executable file is deployed to target machines which need only provide a compatible operating system
The build machine can compile the program to run on different operating systems and CPU architectures, simply by specifying these as arguments to the compiler
Compiled programs run faster, improving application performance and reducing infrastructure costs

Microservices in Action

To get started building a Go microservice, head over to my Go Microservice Repository to explore the technologies I've integrated. You can pick and choose certain technologies to apply to your own project, or fork the repository to start a new project using it as a template.

Technologies Used

For a rundown of tools and frameworks used to bring a Go microservice to life, see the repo readme.

Debugging a Go Application Inside Docker Using VSCode

Bruce MacKenzie — Wed, 03 Aug 2022 23:54:00 +0000

The ability to debug is an important tool for a developer to keep in their toolbox. While it's ideal to debug by running the application natively, there are scenarios where this either isn't possible or the issue must be reproduced in a particular environment.

The required setup to debug a Go app running inside a Docker container is non-trivial. In this post I will walk through the configuration to achieve this using VSCode and the Delve debugger.

Consider this simple Go server app which listens on port 80 and has a simple handler at the GET /hello endpoint:



package main

import (
    "fmt"
    "net/http"
)

func hello(w http.ResponseWriter, req *http.Request) {
    fmt.Println("/hello endpoint called")
    fmt.Fprintf(w, "hello\n")
}

func main() {
    http.HandleFunc("/hello", hello)
    fmt.Println("Server up and listening...")
    http.ListenAndServe(":80", nil)
}

And the Dockerfile:



FROM golang:1.18-alpine
WORKDIR /app
EXPOSE 80

COPY hello.go ./
ENV GO111MODULE=off
RUN go build -o hello-app .

CMD [ "./hello-app" ]

golang:1.18-alpine is the base image we'll build from
WORKDIR /app declares the working directory; all relative paths referenced thereafter are from this location
The COPY directive simply copies files from the host to the image being built
RUN go build -o hello-app . compiles our program, producing the executable file hello-app
- Since we are not working with Go Modules ENV GO111MODULE=off is required to build our program correctly
Finally, CMD provides Docker with a run command for our app when the container is started

Build, run, and query with these commands:



docker build . --tag hello-image
docker run --publish 80:80 --name hello-image hello-server
curl http://localhost/hello

Note: Docker Compose is a more user-friendly tool for managing container lifecycle, but for the sake of simplicity I've decided to work with Docker directly.

Delve provides a server running in the Docker container which VSCode connects to in order to interact with the debugging session.

This requires creating a new Dockerfile with modifications from the original. We'll call this file Dockerfile.debug:



FROM golang:1.18-alpine
EXPOSE 80 4000
WORKDIR /app
COPY hello.go ./

RUN CGO_ENABLED=0 go install -ldflags "-s -w -extldflags '-static'" github.com/go-delve/delve/cmd/dlv@latest

ENV GO111MODULE=off
RUN CGO_ENABLED=0 go build -gcflags "all=-N -l" -o hello-app .

CMD [ "/go/bin/dlv", "--listen=:4000", "--headless=true", "--log=true", "--accept-multiclient", "--api-version=2", "exec", "/app/hello-app" ]

There are a few differences here:

We install the Delve package with RUN CGO_ENABLED=0 go install...
We've added the flag -gcflags "all=-N -l" to the build command. This is to disable inlining and optimizations that can interfere with debugging.
CMD is now running Delve, telling it to listen for connections on port 4000, and how to run our program

We also need a custom debug configuration for VSCode, stored in .vscode/launch.json:



{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Remote Docker App",
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "port": 4000,
            "host": "127.0.0.1"
        }
    ]
}

Running the debug container requires slightly different commands:



docker build . --tag debug-image --file Dockerfile.debug
docker run --publish 80:80 --publish 4000:4000 --name debug-server debug-image

The non-standard filename Dockerfile.debug must be explicitly referenced
There is an additional port to publish, 4000
We use a different image tag and container name so we don't overwrite the original build
- This speeds up build time when switching between the debug and standard environments

At this point we are ready to debug our program! Go to the Run and Debug tab, select Remote Docker App and hit the Start Debugging play button.

Set a breakpoint in our program's hello() handler function by clicking on the margin to the left of the line number.

Finally, curl the server with the command provided earlier, and observe the debugger halting execution!

With our program now running in a debugging session we've gained valuable visibility into runtime internals. This greatly speeds up the feedback loop when trying to understand why our program isn't behaving the intended way. Setting breakpoints and stepping through execution with a debugger is pretty seamless. By contrast adding print statements, building, running, then calling the application is a much slower process.

From here you're free to play around with the many debugger features VSCode offers: Setting breakpoints, stepping line-by-line through execution with Debug Actions, Inspecting variables' values, and so on.

Here are some references to check out:

Debugging with VSCode
My Go Microservice App as a working example of this exercise

Comments and feedback about this tutorial are welcome. If you worked through the example please share your experience with it. Happy debugging!