I’ve been tryign to bring up a single page application for a course project. Here’s what I like to remember:

I ended up writing couple of scripts this weekend to manage snapshots of Azure Disks attached to AKS Nodes. First script goes through all thePersistentVolume objects in AKS (default context, all namespaces) and tries to take an incremental snapshot. A new snapshot is created every Monday, otherwise an incremental backup is taken on the existing snapshot. Second script goes through all snapshots in a resource group and deletes the ones older than the expiry date. They depend on bash, jq, kubectl, and az.

Azure provides the following 4 tech for building workflows. They all support: Input -> (Condition | Action)* -> Output

I had to migrate bunch of aspnet core projects from 2.2 to 3.1 recently. I managed to automate a small portion of the process to get things rolling:

One of the proposed advantages of an orchestration system for microservices like Kubernetes is the better resource allocation. How does Kubernetes do this?

Notes:

• In Linux first process is always pid 0 i.e. kernel
• First user space process is always pid 1 i.e. init
• First process in a new process namespace also gets the pid 1 within that namespace
  • From outside (or rather from the parent namespaces’ pov) it will have a separate pid
• The process with pid 1 is special:
  • A process whose parent dies automatically gets attached to this process
  • It doesn’t get all the signal handlers hooked up automatically
  • If it dies, everything else in that namespace will be destroyed
    • And if it dies in the root namespace, kernel will panic and you reboot your machine
• Docker runs your process (i.e. service etc whatever you’re running in your container) as pid 1
  • Is your process ready to handle aforementioned special attributes?
    • Will it reap the children?
    • Will it terminate them gracefully if it receives a SIGTERM?
  • If you pass --init to docker it would create an init process for you. (See https://docs.docker.com/engine/reference/run/#specify-an-init-process)
• Rkt automatically runs an init process (i.e. systemd) and your container process runs as pid 2
• By default pid namespace is not shared across containers of the same pod in kubernetes
  • In v1.13 there is a feature turn on process namespace sharing (see https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/). If this is turned on, none of you containers will have a process with pid 1 but rather it will be in the pause container. (And yup pause container does what a proper pid 1 process needs to do.)

References:

For an explanation of pid namespaces see here For an explanation of pause container see here For an explanation of the zombie reaping problem see here Tini - A tiny but valid init for containers Dumb-init See here for a blog post by Yelp engineering explaining the reasoning behind dumb-init and how it works.

Relationship between multiple containers is a decent way to understand what a pod in the world of k8s is. As you probably know containers provide operating-system-level virtualization. In Linux this virtualization is achieved via namespaces. By default, all containers within a pod share network, and ipc namespaces. In v1.13 you can also set the shareProcessNamespace to share the process namespace between containers in the same pod. See here for more info on this.

If you use nested branches in git, some planning (or predefine structure) could be useful. Turns out the last part of your nested branch (e.g. foo in feature/foo) is a file. Therefore, you cannot create feature/foo/bar once feature/foo is created. If you think you will nest branches multiple levels, better prepare for it via some convention like feature/foo/main and then you can branch to feature/foo/bar.

Cancellation Token | Alexander Grebenyuk A nice introduction to cancellation tokens.

Programming against event hubs can be tricky but luckily Microsoft provides EventHubProcessorHost to make your life easier. It supports checkpoint and lease management out of the box.

k8s and containers

Understanding kubernetes networking: pods – Google Cloud Platform - Community – Medium Understanding kubernetes networking: services – Google Cloud Platform - Community – Medium Understanding kubernetes networking: ingress – Google Cloud Platform - Community – Medium A three part series on k8s networking internals.

Public vs Published Interfaces Published interfaces are public interfaces for which you don’t have control over the callers.

Here’s a simple powershell script that parses the ARM output and sets a variable for each individual top level property.

A powershell script that generates password and sets it on the given vso variable. Mostly based off of this.

Gitflow Workflow | Atlassian Git Tutorial De-Facto branching strategy for managing git repositories.

Next you can update your site name, avatar and other options using the _config.yml file in the root of your repository (shown below).