Blog - sandboxdaily.com

Featured

Docker Compose 101: use it on Simple .Net Core API

cooshbrown@gmail.comSeptember 28, 2024October 9, 2024.Net Core, Docker, Docker Compose, MicroservicesLeave a comment

Docker Compose is a tool that you will use to define and share multi-container applications. This means you can run a project with multiple containers using a single source, you will need to create a YAML file to define the services you need and run with a single command.

docker-compose.yml

services:
  simplecore.api:
    container_name: simplecoreapi.from.docker.composed
    #image: bindplus.api.v2                # will use image
    image: ${DOCKER_REGISTRY-}simplecoreapi:1.0.0    # will use Dockerfile
    build:
      context: . # ASP-NET-Core-Simple-API replace with the actual name of your project, docker file location
      dockerfile: ASP-NET-Core-Simple-API/Dockerfile
    ports:
      - 49195:80    #[targer port]:[docker file port]

The docker-compose.override.yml is the configuration file where you can override existing settings from the docker-compose.yml or can even add completely new services.

docker-compose.override.yml

services:
  simplecore.api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - LogJson__Path=Payload 
    volumes:
      - /tmp/Payload:/app/Payload         # [Local path]:[container path]

Run docker compose using the command: docker compose up -d //daemon

$ docker compose up -d
[+] Running 1/2
 ⠼ Network projects_default                      Created                                                                                                                                                 0.5s 
 ✔ Container simplecoreapi.from.docker.composed  Started

The figure below shows we tested the api if it is running after running docker compose and shutting it down using the command: docker compose down

$ curl http://localhost:49195/api/values
{"machineName":"6ac7227899e2","environment":"Development","logJsonPath":"Payload"}
$ docker compose down
[+] Running 2/2
 ✔ Container simplecoreapi.from.docker.composed  Removed                                                                                                                        0.2s 
 ✔ Network projects_default                      Removed

Kubernets ConfigMaps and Secrets

cooshbrown@gmail.comFebruary 8, 2026February 8, 2026Docker, Kubernetes, MapConfig, SecretLeave a comment

ConfigMaps vs Secrets (big picture)

Both are ways to inject configuration into Pods without baking it into container images.

Feature	ConfigMap	Secret
Purpose	Non-sensitive config	Sensitive data
Examples	URLs, feature flags, env names	Passwords, tokens, certs
Stored in etcd	Plaintext	Base64-encoded (not encrypted by default)
Size limit	~1MB	~1MB
Can be env vars	Yes	Yes
Can be mounted as files	Yes	Yes

Let’s try it!

Create new dotnet api

add configuration for configmap and secret in appsettings.json:

"AppConfig": {
    "ServiceName": "My Awesome API"
},
"UserConfig":{
    "SecretPassword": "User Secret"
},

In program.cs, let’s assign variables to the configurations

var serviceName = builder.Configuration["AppConfig:ServiceName"]; // Access the ConfigMap value
var userPassword = builder.Configuration["UserConfig:SecretPassword  "]; // Access the Secret value

var app = builder.Build();

Create a controller to view the configs:

app.MapGet("/getconfigs", () =>
{
    var response = new { 
        Version = "V1",  
        Service = serviceName, 
        Password = userPassword, 
        Machine = System.Environment.MachineName 
    };

    Console.WriteLine(response);
    
    return Results.Ok(response);
});

When you run the application, the resul should be:

$ curl http://localhost:5128/getconfigs
{"version":"V1","service":"My Awesome API","password":"User Secret","machine":"My-MacBook-Air"

Build and image for the application

Create a Docker file:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app/publish

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
EXPOSE 8080
ENTRYPOINT ["dotnet", "my-dotnet-api.dll"]

Build the image:

$ docker build --no-cache -t my-dotnet-api:latest .  --no-cache

Create configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: dotnet-app-config
data:
  # Example non-sensitive key-value pairs
  SERVICE_NAME: "My Awesome API!!!"

Create secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: dotnet-app-secret
type: Opaque
data:
  # Base64 encoded: "s3cretP@ssw0rd"
  PASSWORD: "czNyZXRQQHNzd2ByZA=="

Create service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-dotnet-api-service
spec:
  type: LoadBalancer
  selector:
    app: my-dotnet-api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Create deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-dotnet-api-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: my-dotnet-api
  template:
    metadata:
      labels:
        app: my-dotnet-api
    spec:
      containers:
        - name: my-dotnet-api
          image: my-dotnet-api:latest
          imagePullPolicy: Always #Default: IfNotPresent
          ports:
            - containerPort: 8080
          env:
              # Get non-sensitive environment variables from the ConfigMap
            - name: APPCONFIG__SERVICENAME # .NET Core configuration format
              valueFrom:
                configMapKeyRef:
                  name: dotnet-app-config
                  key: SERVICE_NAME
              # Get sensitive environment variables from the Secret
            - name: USERCONFIG__SECRETPASSWORD
              valueFrom:
                secretKeyRef:
                  name: dotnet-app-secret
                  key: PASSWORD

Let’s test our work, apply our yaml files and see the result:

$ kubectl apply -f configmap.yaml 
configmap/dotnet-app-config created
$ kubectl apply -f secret.yaml 
secret/dotnet-app-secret created
$ kubectl apply -f service.yaml
service/my-dotnet-api-service created
$ kubectl apply -f deployment.yaml 
deployment.apps/my-dotnet-api-deployment created
$ curl http://localhost/getconfigs
{"version":"V1","service":"My Awesome API!!!","password":"s3retP@ssw`rd","machine":"my-dotnet-api-deployment-7494d875f5-mmm42"}

What if we have some changes in the Configmap? here’s what you can do:

We made some changes in the value for the SERVICE_NAME

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: dotnet-app-config
data:
  # Example non-sensitive key-value pairs
  SERVICE_NAME: "My Awesome API Updated!"

We have 2 options to apply the changes:

kubectl rollout restart deployment my-app

$ kubectl apply -f configmap.yaml 
configmap/dotnet-app-config configured
$ kubectl rollout restart deployment my-dotnet-api-deployment
deployment.apps/my-dotnet-api-deployment restarted
$ curl http://localhost/getconfigs
{"version":"V1","service":"My Awesome API Updated!","password":"s3retP@ssw`rd","machine":"my-dotnet-api-deployment-54bb4888f4-mnfd8"}

Delete all pods: kubectl delete pod <pod-name>

(New Pods will pick up the updated ConfigMap)

Note: When you re-applied the configmap, the result says: configured, meaning the changes were applied, however, if there are no changes, the result will be: configmap/dotnet-app-config unchanged

To Clean Up:

kubectl delete deployment my-dotnet-api-deployment
kubectl delete service my-dotnet-api-service
kubectl delete secret dotnet-app-secret
kubectl delete configmap dotnet-app-config

Introduction to Kubernetes

cooshbrown@gmail.comFebruary 4, 2026February 4, 2026Kubernetes, MicroservicesLeave a comment

Kubernetes (often called K8s) is an open-source platform for automating the deployment, scaling, and management of containerized applications. Kubernetes helps you manage many containers across multiple machines efficiently.

Why Kubernetes?
Modern applications are often microservices-based—many small services that need to communicate and scale independently. Managing these manually is tough. Kubernetes provides:
Automatic scaling: Adjusts the number of running containers based on demand.

Self-healing: Restarts failed containers automatically.

Service discovery & load balancing: Routes traffic to the right containers.

Rolling updates: Updates applications without downtime.

Storage orchestration: Connects applications to storage systems automatically.

Think of it as a traffic controller and manager for containers, ensuring they run reliably, scale efficiently, and communicate properly.

Core concepts
Cluster: A group of machines (nodes) where Kubernetes runs your applications. There’s usually a master node (control plane) and worker nodes.

Node: A single machine (physical or virtual) that runs your containerized apps.

Pod: The smallest deployable unit in Kubernetes. It can contain one or more containers that share resources like storage and network.

Deployment: Defines how to run and scale your pods (e.g., “run 5 instances of this app”).

Service: Exposes your pods to the network and balances traffic between them.

ConfigMap / Secret: Manage configuration and sensitive data separately from your application code.

Ingress: Manages external access to your services, usually via HTTP/HTTPS.

Kubernetes Architecture

Control Plane (Master Node):
API Server: Entry point for all commands.
Scheduler: Decides where pods should run.
Controller Manager: Maintains desired state (e.g., number of pods).
Worker Nodes: Run the pods and containers.
Kubelet: Ensures containers in pods run as expected.
Kube-proxy: Handles networking and load balancing.
Add-ons:
Ingress for external traffic.
ConfigMaps/Secrets for configuration and sensitive data.

Kubernetes Basics

kubectl – CLI to interact with Kubernetes.
Cluster – Set of nodes (master + worker nodes).
Node – VM or physical machine running pods.
Pod – Smallest deployable unit; can contain one or more containers.
Deployment – Manages stateless apps, scaling, and rolling updates.
Service – Exposes pods inside or outside the cluster.
Namespace – Virtual cluster for resource isolation.

Common kubectl Commands

# Cluster info
kubectl cluster-info

# Get resources
kubectl get nodes
kubectl get pods
kubectl get services
kubectl get deployments
kubectl get configmaps
kubectl get secrets

# Get resources with details
kubectl describe pod <pod-name>
kubectl describe node <node-name>

# Create resources from YAML
kubectl apply -f <file.yaml>
kubectl create -f <file.yaml>

# Delete resources
kubectl delete pod <pod-name>
kubectl delete -f <file.yaml>

# Logs and debugging
kubectl logs <pod-name>           # Single container pod
kubectl logs <pod-name> -c <container-name>
kubectl exec -it <pod-name> -- /bin/bash

# Scaling
kubectl scale deployment <name> --replicas=<n>

# Configurations
kubectl config view
kubectl config use-context <context>

Pod Management

# Run a pod
kubectl run my-pod --image=nginx --restart=Never

# Expose pod as a service
kubectl expose pod my-pod --type=NodePort --port=80

# Port forwarding
kubectl port-forward pod/my-pod 8080:80

Deployment Management

# Create a deployment
kubectl create deployment my-deploy --image=nginx

# Update deployment image
kubectl set image deployment/my-deploy nginx=nginx:latest

# Rollback
kubectl rollout undo deployment/my-deploy

# View rollout status
kubectl rollout status deployment/my-deploy

Services

ClusterIP – Default, internal only.
NodePort – Exposes service on each node’s port.
LoadBalancer – External load balancer (cloud provider).
ExternalName – Maps service to external DNS.

kubectl expose deployment my-deploy --type=LoadBalancer --name=my-service
kubectl get svc

ConfigMaps & Secrets

# Create ConfigMap from file
kubectl create configmap my-config --from-file=config.properties

# Create Secret from literal
kubectl create secret generic my-secret --from-literal=password=12345

# View (encoded) secret
kubectl get secret my-secret -o yaml

# Decode secret
echo "base64-encoded-value" | base64 --decode

Scaling & Autoscaling

# Manual scaling
kubectl scale deployment my-deploy --replicas=5

# Horizontal Pod Autoscaler (HPA)
kubectl autoscale deployment my-deploy --cpu-percent=50 --min=2 --max=10
kubectl get hpa

Namespaces

# Create namespace
kubectl create namespace my-namespace

# Use namespace
kubectl config set-context --current --namespace=my-namespace

# Get resources in namespace
kubectl get pods -n my-namespace

Useful Tips

kubectl get all – Lists all resources in current namespace.
kubectl get pods -o wide – Shows node and IP info.
kubectl explain <resource> – Shows documentation for a resource.
kubectl diff -f <file.yaml> – Preview changes before applying.

Horizontal Pod Autoscaler Walkthrough

cooshbrown@gmail.comJanuary 16, 2026January 16, 2026KubernetesHPA, KubernetesLeave a comment

Install Metrics server by running the following commands:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Installation output:

serviceaccount/metrics-server created<br>clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created<br>clusterrole.rbac.authorization.k8s.io/system:metrics-server created<br>rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created<br>clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created<br>clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created<br>service/metrics-server created<br>deployment.apps/metrics-server created<br>apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

Check metrics server deployment in yaml output:

kubectl -n kube-system get deployment metrics-server -o yaml

We will patch the deployment to have the following settings:

Add –kubelet-insecure-tls argument to containers args – used to skip verifying Kubelet CA certificates.
Change the container port from 10250 to port 4443
Add hostNetwork: true¹

kubectl patch deployment metrics-server -n kube-system --type='json' -p='[
{
"op": "add",
"path": "/spec/template/spec/hostNetwork",
"value": true
},
{
"op": "replace",
"path": "/spec/template/spec/containers/0/args",
"value": [
"--cert-dir=/tmp",
"--secure-port=4443",
"--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname",
"--kubelet-use-node-status-port",
"--metric-resolution=15s",
"--kubelet-insecure-tls"
]
},
{
"op": "replace",
"path": "/spec/template/spec/containers/0/ports/0/containerPort",
"value": 4443
}
]'

Check update output:

deployment.apps/metrics-server patched

After a few seconds the pod status should be running and active:

kubectl -n kube-system get pods -l k8s-app=metrics-server
NAME                              READY   STATUS    RESTARTS   AGE
metrics-server-5478cc86f5-2h247   1/1     Running   0          2m25s

Check the metrics API status:

kubectl get apiservices -l k8s-app=metrics-server
NAME                     SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io   kube-system/metrics-server   True        79m

Test if the metrics server is running by checking the kubernetes nodes utilization

kubectl top nodes
NAME                    CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
desktop-control-plane   192m         0%       584Mi           3%
desktop-worker          26m          0%       130Mi           0%
desktop-worker2         34m          0%       159Mi           1%

Run and expose php-apache server

kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
deployment.apps/php-apache created
service/php-apache created

Create the HorizontalPodAutoscaler

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
Flag --cpu-percent has been deprecated, Use --cpu with percentage or resource quantity format (e.g., '70%' for utilization or '500m' for milliCPU).
horizontalpodautoscaler.autoscaling/php-apache autoscaled

You can check the current status of the newly created Horizontal Pod Autoscaler, by running:

(You can use “hpa” or “horizontalpodautoscaler”; either name works OK.)

kubectl get hpa
NAME         REFERENCE               TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   cpu: 0%/50%   1         10        1          48s

If you see other HorizontalPodAutoscalers with different names, it means they already existed and this is usually not an issue.

Please note that the current CPU utilization is 0% because no clients are sending requests to the server. The TARGET column reflects the average CPU usage across all Pods managed by the corresponding deployment.

Let’s increase the load

Next, observe how the autoscaler responds to increased load. To do this, you will start a separate Pod that acts as a client. The container inside this client Pod runs an infinite loop, continuously sending requests to the php-apache service.

Note: It’s better to run this in a separate terminal so that the load generation continues and you can carry on with the rest of the steps

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
If you don't see a command prompt, try pressing enter.
OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK

Now run: (type Ctrl+C to end the watch when you’re ready)

kubectl get hpa php-apache --watch
NAME         REFERENCE               TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   cpu: 129%/50%   1         10        5          18m

Within a minute or so, you should see the higher CPU load; for example:

NAME         REFERENCE               TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   cpu: 0%/50%   1         10        1          113s

and then, more replicas. see example:

NAME         REFERENCE               TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   cpu: 129%/50%   1         10        5          18m
php-apache   Deployment/php-apache   cpu: 59%/50%    1         10        5          18m
php-apache   Deployment/php-apache   cpu: 66%/50%    1         10        5          18m
php-apache   Deployment/php-apache   cpu: 59%/50%    1         10        7          19m

Here, CPU consumption has increased to 305% of the request. As a result, the Deployment was resized to 7 replicas
and also, you should see the replica count matching the figure from the HorizontalPodAutoscaler

kubectl get deployment php-apache
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   7/7     7            7           23m

Note:
It may take a few minutes for the number of replicas to stabilize. Because the load is not explicitly controlled, the final replica count may differ from the example shown.

Stop generating load
To complete the example, stop sending traffic to the service.

In the terminal where you started the Pod running the BusyBox image, stop the load generation by pressing Ctrl + C.

Then, after about a minute, verify the resulting state:

kubectl get hpa php-apache --watch
NAME         REFERENCE               TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   cpu: 0%/50%   1         10        1          45m

and the Deployment also shows that it has scaled down:

kubectl get deployment php-apache
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   1/1     1            1           50m

Once CPU utilization dropped to 0, the HPA automatically scaled the replicas back down to 1. Please note that autoscaling adjustments may take a few minutes to complete.

Clean Up Resources

Once you have finished the demo, delete the resources:

kubectl delete deployment php-apache
kubectl delete service php-apache
kubectl delete hpa php-apache

A simple introduction to Kubernetes

cooshbrown@gmail.comOctober 12, 2024October 12, 2024Docker, Kubernetes, Microservices, MinikubeMinikubeLeave a comment

What you will learn:

In this tutorial you will learn:

Introduction to kubernetes using the simple .net core api image from docker container registry
Basic nderstanding of deployment and service yaml file in kubernetes.
Using minikube

Kubernetes Service and Deployment are two fundamental components of the Kubernetes ecosystem.

The Service acts as the gateway for communication and load balancing. On the other hand, Deployment orchestrates the management and scaling of your application’s replicas.

deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: simple-core-api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: simple-core-api
  template:
    metadata:
      labels:
        app: simple-core-api
    spec:
      containers:
      - name: simple-core-api
        image: sandboxdaily/simplecoreapi:1.0.0
        imagePullPolicy: Always
        ports:
        - containerPort: 80

$ kubectl apply -f deploy.yml
$ kubectl get pods
NAME                                          READY   STATUS    RESTARTS      AGE
demo-app                                      1/1     Running   4 (22h ago)   13d
simple-core-api-deployment-69bdc96c97-6nj6b   1/1     Running   4 (22h ago)   13d
simple-core-api-deployment-69bdc96c97-kf42t   1/1     Running   4 (22h ago)   13d
simple-core-api-deployment-69bdc96c97-m5mf7   1/1     Running   4 (22h ago)   13d
$ kubectl get deployments
NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
simple-core-api-deployment   3/3     3            3           11d

Note: if kubectl apply -f deploy.yml doesn’t work, run this in console: $ minikube start (see below about minikube)

service.yml

# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
  name: simple-core-api
spec:
  selector:
    app: simple-core-api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

$ kubectl apply -f service.yml
$ kubectl get svc
NAME              TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes        ClusterIP      10.96.0.1        <none>        443/TCP        11d
simple-core-api   LoadBalancer   10.104.243.171   127.0.0.1     80:30804/TCP   11d

$ curl http://127.0.0.1/api/values
{"machineName":"simple-core-api-deployment-69bdc96c97-kf42t","environment":null,"logJsonPath":"payloads-base"}

Note: if the api is not working, run this in console: $ minikube tunnel (see below about minikube)

$ kubectl get pods
NAME                                          READY   STATUS    RESTARTS      AGE
demo-app                                      1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-6nj6b   1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-kf42t   1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-m5mf7   1/1     Running   4 (23h ago)   13d
$ kubectl delete pod simple-core-api-deployment-69bdc96c97-6nj6b
pod "simple-core-api-deployment-69bdc96c97-6nj6b" deleted
$ kubectl get pods
NAME                                          READY   STATUS              RESTARTS      AGE
demo-app                                      1/1     Running             4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-kf42t   1/1     Running             4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-m5mf7   1/1     Running             4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-xcr9j   0/1     ContainerCreating   0             2s

$ kubectl get pods
NAME                                          READY   STATUS    RESTARTS      AGE
demo-app                                      1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-kf42t   1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-m5mf7   1/1     Running   4 (23h ago)   13d
simple-core-api-deployment-69bdc96c97-xcr9j   1/1     Running   0             69s

What is minikube?

Minikube is a lightweight and simplified version of Kubernetes, primarily used for local development and testing purposes.

What is minikube used for?

You can use Minikube to learn how to deploy and manage applications in Kubernetes.

Minikube can be used to develop Kubernetes applications and test your applications before deploying them to production.

What is the difference between Kubernetes and minikube?

On the Deployment Scale: Kubernetes is designed for large-scale deployments across multiple nodes and clusters, making it suitable for managing complex and distributed environments. On the other hand, Minikube is a lightweight and simplified version of Kubernetes, suitable for local development and testing purposes.

$ minikube start
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│                                                                                                          │
│    You are trying to run the amd64 binary on an M1 system.                                               │
│    Please consider running the darwin/arm64 binary instead.                                              │
│    Download at https://github.com/kubernetes/minikube/releases/download/v1.32.0/minikube-darwin-arm64    │
│                                                                                                          │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────╯
😄  minikube v1.32.0 on Darwin 14.5
🎉  minikube 1.34.0 is available! Download it: https://github.com/kubernetes/minikube/releases/tag/v1.34.0
💡  To disable this notice, run: 'minikube config set WantUpdateNotification false'

✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔄  Restarting existing docker container for "minikube" ...
🐳  Preparing Kubernetes v1.28.3 on Docker 24.0.7 ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

$ minikube tunnel
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│                                                                                                          │
│    You are trying to run the amd64 binary on an M1 system.                                               │
│    Please consider running the darwin/arm64 binary instead.                                              │
│    Download at https://github.com/kubernetes/minikube/releases/download/v1.32.0/minikube-darwin-arm64    │
│                                                                                                          │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✅  Tunnel successfully started

📌  NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...

❗  The service/ingress simple-core-api requires privileged ports to be exposed: [80]
🔑  sudo permission will be asked for it.
🏃  Starting tunnel for service simple-core-api.
Password:

References:

docker image: https://hub.docker.com/repository/docker/sandboxdaily/simplecoreapi/general

Build and Push Docker images to Docker hub registry

cooshbrown@gmail.comSeptember 28, 2024October 12, 2024Docker, MicroservicesLeave a comment

Dockerize Simple .Net Core API

cooshbrown@gmail.comSeptember 22, 2024September 28, 2024.Net Core, Docker, MicroservicesLeave a comment

Requirements:

Docker Desktop
Git scm
Postman

Build Steps

Step 1: Let’s grab the Simple Core Api project!

Clone the Simple Core API from Github or download the source code.

$ git clone  https://github.com/sandboxdaily/ASP-NET-Core-Simple-API.git

Step 2: Docker File

Let’s add the Dockerfile with this content: (File may be already in the repository)

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443


# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["SimpleCoreApi/SimpleCoreApi.csproj", "SimpleCoreApi/"]
RUN dotnet restore "./SimpleCoreApi/SimpleCoreApi.csproj"
COPY . .
WORKDIR "/src/SimpleCoreApi"
RUN dotnet build "./SimpleCoreApi.csproj" -c $BUILD_CONFIGURATION -o /app/build

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./SimpleCoreApi.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SimpleCoreApi.dll"]

Step 3: Docker image

Create docker image using this command: docker build -t [image name] [docker file location]

Example:

docker build -t simplecoreapi:1.0.0 .

Step 4: Docker Container

Create docker container using this command: docker run -d -p [port]:[exposed port] –name [container name] [image name]
Example: (Note it will return the container id)

$ docker run -d -p 2439:80 --name simplecoreapi simplecoreapi:1.0.0
1653c712c4b926ed9f32474dfa80c859ac7d910f9a2202cdadacd5f1da870239

Note: exposed port should be the same as the exposed port in the docker file.

Step 5: Let’s test it!

Testing our container using Postman:

Accessing the files in the container

The snap shot below is from Docker desktop, you can see that the files generated by the api are stored in the payloads-default folder, which is configure in the appsettings.json:

Docker Container Shell

We can also access the files saved using the docker container shell, here I will show you, take note I switched to my windows machine, here’s what I did:

We need to get the container Id using the command: docker ps
Run bash inside the container using the command: docker exec -it 1653 sh //1653 is the first 4 character of the container id
inside the shell, change the directory to payloads-default to list the files created.

C:\SandBoxDaily\ASP-NET-Core-Simple-API>docker ps
CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS         PORTS                           NAMES
1653c712c4b9   simplecoreapi:1.0.0   "dotnet SimpleCoreAp…"   11 minutes ago   Up 5 minutes   443/tcp, 0.0.0.0:2439->80/tcp   simplecoreapi

C:\SandBoxDaily\ASP-NET-Core-Simple-API>docker exec -it 1653 sh
#  ls
Microsoft.OpenApi.dll  SimpleCoreApi.deps.json  SimpleCoreApi.pdb                 Swashbuckle.AspNetCore.Swagger.dll     Swashbuckle.AspNetCore.SwaggerUI.dll  appsettings.Staging.json  payloads-default
Newtonsoft.Json.dll    SimpleCoreApi.dll        SimpleCoreApi.runtimeconfig.json  Swashbuckle.AspNetCore.SwaggerGen.dll  appsettings.Development.json          appsettings.json          web.config
# cd payloads-default
# ls
'\20240923121413.json'  '\20240923121633.json'

Copy files from container to local

Command: docker cp [container id] :[container file path] [local destination]

C:\SandBoxDaily>docker cp 1653c712c4b9:/app/appsettings.json .
Successfully copied 2.05kB to C:\SandBoxDaily\.

Copy file from local to container

Command: docker cp [local file] [container id]:[container path]

C:\SandBoxDaily>docker cp helloworld.txt 1653c712c4b9:/app
Successfully copied 2.05kB to 1653c712c4b9:/app

Environment Variables

You can pass environment variables to your containers with the -e (alias --env) flag, e.g. :

Note: Don’t use environment variables to pass sensitive information, such as passwords, in to your containers, use secrets instead.

Example:

# docker run -d -p 2439:80 -e "ASPNETCORE_ENVIRONMENT=Development" -e "LogJson__Path=Payloads" --name simplecoreapi simplecoreapi:1.0.0

In the excerpt of the saved payload below, notice that the values of the Environment and LogJsonPath are from the environment passed.

Note:

· “LogJson__Path=Payloads” is the same as in appsettings.json: “LogJson”: { “Path”: ” payloads” }

· Will work if not assigned/declared in appsettings.json

· Overriding appsettings file

· To override environment variables, remove them from the appsettings file

Docker Volumes

Volumes are a mechanism for storing data outside containers. All volumes are managed by Docker and stored in a dedicated directory on your host, usually /app for Macbook systems.

Volumes are mounted to filesystem paths in your containers. When containers write to a path beneath a volume mount point, the changes will be applied to the volume instead of the container’s writable image layer.

Volume parameters: add -v [local path]:[container path]

$ docker run -d -p 2439:80 -v /tmp/Payloads:/app/Payloads -e "ASPNETCORE_ENVIRONMENT=Development" -e "LogJson__Path=Payloads" --name simplecoreapi simplecoreapi:1.0.0 
703b9d6be839b28d38e0d75232d384b3bcd5b7ad0189d179d16d2356d8a5fa78
$ curl http://localhost:2439/api/values
{"machineName":"703b9d6be839","environment":"Development","logJsonPath":"Payloads"}Augustuss-MacBook-Air:ASP-NET-Core-Simple-API dags$

References:

Build and Push Your Own Docker Images to DockerHub

Create a simple .Net Core API

cooshbrown@gmail.comSeptember 21, 2024October 12, 2024.Net Core

Objective

Our Objective is to create a simple .net core api that we will be using for other tutorials like Dockerizing the api and deploying to azure web api .

The complete source code of the api can be found in here in Github.

I’ve created a new .net core web api project and added new defaul controller and added some codes, see below:

[Route("api/[controller]")]
    [ApiController]
    public class ValuesController : ControllerBase
    {
        private readonly IConfiguration _config;
        public ValuesController(IConfiguration config)
        {
            _config = config;
        }

        [HttpGet]
        public IActionResult Get()
        {
            bool enabledLog;           
            Boolean.TryParse(_config.GetValue<string>("LogJson:Enabled"), out enabledLog);                      

            var logFolder = _config.GetValue<string>("LogJson:Path");

            var result = new
            {
                MachineName = Environment.MachineName,
                Environment = _config.GetValue<string>("ASPNETCORE_ENVIRONMENT"),
                LogJsonPath = logFolder
            };

            if (!enabledLog)
                return Ok(result);

            if (!Directory.Exists(logFolder))
            {
                Directory.CreateDirectory(logFolder);
            }

            var jsonBody = JsonConvert.SerializeObject(result, Newtonsoft.Json.Formatting.Indented);

            if (jsonBody.Length > 0)
            {
                System.IO.File.WriteAllText($"{logFolder}\\{DateTime.Now.ToString("yyyyMMddHHmmss")}.json", jsonBody);
            }

            return Ok(result);
        }

The controller returns a new anonymous object with the following information: Machine name, Environment and the log folder settings (LogJson) :

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "LogJson": {
    "Path": "payloads-default",
    "Enabled": true
  }
}