Zero to Hero - cloud-native

Understanding Docker's 6MB Memory Limit: A Deep Dive

2024-12-12T00:00:00+00:00

Have you ever encountered this puzzling error message while working with Docker containers?</p>

Warning Failed 89s (x12 over 3m44s) kubelet Error: Error response from daemon: Minimum memory limit allowed is 6MB</span></span></code></pre>
If you’re like many developers, your first instinct might be to check Kubernetes’ LimitRange resources:</p>
$</span> kubectl get limitrange</span> -A</span></span>
No</span> resources found</span></span></code></pre>
But wait - if there are no LimitRange resources defined, where is this 6MB limit coming from? Let’s dive deep into this common containerization puzzle.</p>
The Mystery of the 6MB Limit</h2>
The key to understanding this issue lies in recognizing that this limit isn’t coming from Kubernetes at all - it’s actually a built-in restriction in Docker itself. This often surprises developers because it’s not documented prominently in Docker’s documentation.</p>
Why Does This Limit Exist?</h3>
The 6MB minimum memory limit serves as a critical safeguard in Docker’s architecture. It’s designed to prevent containers from being started with dangerously low memory limits that could lead to:</p>

Immediate Out-of-Memory (OOM) kills</li>
Unstable container behavior</li>
System resource exhaustion</li>
Cascading failures in container orchestration</li>
</ul>
Configuration Options: What Can You Do?</h2>
While this limit is hardcoded into Docker’s engine, you’re not entirely without options. Here are several approaches to dealing with this limitation:</p>
1. Adjust Your Resource Allocation</h3>
The most straightforward solution is to ensure your containers have adequate memory allocation. If you’re hitting this limit, it’s worth questioning whether running with such minimal memory is truly optimal for your application.</p>
2. Alternative Approaches</h3>
If you absolutely need to work with very low memory limits, consider these options:</p>

Use Docker Swarm with Compatibility Mode</strong>: Running Docker Swarm with the --compatibility</code> flag can alter how memory limits are interpreted</li>
Switch Container Runtimes</strong>: Consider using containerd or another container runtime that doesn’t impose this limitation</li>
Custom Docker Build</strong>: Though not recommended for production, you could technically modify Docker’s source code to adjust this limit</li>
</ul>
Best Practices and Recommendations</h2>
When working with container memory limits, consider these best practices:</p>

Right-size Your Containers</strong>: Instead of trying to run with minimal memory, focus on appropriate sizing based on actual application needs</li>
Monitor Memory Usage</strong>: Use tools like cAdvisor or Prometheus to understand your actual memory usage patterns</li>
Test Thoroughly</strong>: Always test your containers under load to ensure memory limits are appropriate</li>
Document Your Settings</strong>: Make memory requirements and limits explicit in your deployment documentation</li>
</ol>
Conclusion</h2>
While Docker’s 6MB memory limit might seem restrictive at first, it’s actually a thoughtful safeguard that helps prevent potentially problematic container configurations. Understanding this limit - and working with it rather than against it - will help you build more reliable containerized applications.</p>
Remember: Just because you can run a container with minimal memory doesn’t always mean you should. Focus on stability and reliability over minimal resource usage unless you have a compelling reason to do otherwise.</p>
Additional Resources</h3>

Docker Documentation on Resource Constraints</li>
Kubernetes Memory Management Documentation</li>
Container Runtime Comparisons</li>
Memory Optimization Strategies for Containers</li>
</ul>
Happy containerizing!</p>



Building a Secure Webhook Server with Go and Docker: A Step-by-Step Guide
2024-12-11T00:00:00+00:00
In this tutorial, we’ll walk through the process of building and containerizing a secure webhook server using Go. We’ll cover everything from setting up the project structure to creating a production-ready Docker container.</p>
Project Overview</h2>
Our webhook server is designed to handle secure GET requests with query parameters, process JSON data, and implement basic authentication. The server listens on port 8443 and includes detailed request logging for debugging purposes.</p>
Prerequisites</h2>

Go 1.20 or later</li>
Docker</li>
Basic understanding of Go and Docker concepts</li>
</ul>
Project Structure</h2>
Let’s start with our project structure:</p>
.</span></span>
├── Dockerfile</span></span>
├── go.mod</span></span>
└── main.go</span></span></code></pre>The Application Code</h2>
Our main.go</code> implements a webhook server with the following features:</p>

Secure parameter handling with URL decoding</li>
JSON data processing</li>
Path-based data retrieval</li>
Detailed request logging</li>
Basic authentication</li>
</ul>
The server expects requests with a key parameter and returns JSON data based on the provided path. It includes basic security measures like key validation and proper error handling.</p>
Dependencies</h2>
Our go.mod</code> file specifies the project dependencies:</p>
module vsecm</span>-</span>scout</span></span>
</span>
go</span> 1.23.1</span></span>
</span>
require github</span>.</span>com</span>/</span>vmware</span>-</span>tanzu</span>/</span>secrets</span>-</span>manager</span>/</span>sdk v0</span>.</span>28.0</span></span>
</span>
// ... other dependencies ...</span></span></code></pre>Dockerizing the Application</h2>
The Dockerfile for our application uses a multi-stage build process to create a minimal and secure production image. Here’s a breakdown of our Dockerfile:</p>
# Build stage</span></span>
FROM</span> golang:1.20-alpine </span>AS</span> builder</span></span>
</span>
WORKDIR</span> /app</span></span>
</span>
# Copy go mod and sum files</span></span>
COPY</span> go.mod ./</span></span>
</span>
# Download all dependencies</span></span>
RUN</span> go mod download</span></span>
</span>
# Copy the source code</span></span>
COPY</span> main.go ./</span></span>
</span>
# Build the application</span></span>
RUN</span> CGO_ENABLED=0 GOOS=linux go build -o webhook-server .</span></span>
</span>
# Final stage</span></span>
FROM</span> alpine:latest</span></span>
</span>
WORKDIR</span> /root/</span></span>
</span>
# Copy the binary from the builder stage</span></span>
COPY</span> --from=builder /app/webhook-server .</span></span>
</span>
# Expose the port the app runs on</span></span>
EXPOSE</span> 8443</span></span>
</span>
# Run the binary</span></span>
CMD</span> [</span>"./webhook-server"</span>]</span></span></code></pre>Key Features of Our Dockerfile:</h3>


Multi-stage Build</strong>: We use a multi-stage build to keep our final image size small by only including the compiled binary.</p>
</li>

Dependency Management</strong>: The build stage properly handles Go module dependencies.</p>
</li>

Static Binary</strong>: We compile a static binary that will run efficiently in the Alpine container.</p>
</li>

Security</strong>: Using Alpine as the base image reduces the attack surface of our container.</p>
</li>
</ol>
Building and Running the Container</h2>
To build your Docker image:</p>
docker</span> build</span> -t</span> vsecm-scout .</span></span></code></pre>
To run the container:</p>
docker</span> run</span> -p</span> 8443:8443 vsecm-scout</span></span></code></pre>Best Practices Implemented</h2>


Security</strong>:</p>

URL parameter decoding for safe input handling</li>
Basic authentication with key validation</li>
Proper error handling and status codes</li>
</ul>
</li>

Docker Best Practices</strong>:</p>

Multi-stage builds for smaller images</li>
Proper dependency management</li>
Clear and maintainable Dockerfile structure</li>
</ul>
</li>

Golang Best Practices</strong>:</p>

Clear error handling</li>
Structured logging</li>
Clean code organization</li>
</ul>
</li>
</ol>
Testing the Webhook Server</h2>
Once running, you can test the webhook server with a curl command:</p>
curl</span> "</span>http://localhost:8443/webhook?key=key=coca-cola.cluster-001%26path=namespaces.cokeSystem.secrets.adminCredentials</span>"</span></span></code></pre>Conclusion</h2>
This setup provides a solid foundation for a production-ready webhook server. The combination of Go’s robust standard library and Docker’s containerization makes it easy to deploy and scale this service in any environment.</p>
Remember to always follow security best practices when deploying webhook servers in production environments, such as:</p>

Using HTTPS in production</li>
Implementing rate limiting</li>
Adding more comprehensive authentication</li>
Monitoring and logging</li>
Regular security updates</li>
</ul>
Next Steps</h2>
Consider enhancing the application with:</p>

TLS support</li>
Rate limiting</li>
Comprehensive logging</li>
Metrics collection</li>
Health check endpoints</li>
</ul>
Happy coding!</p>


Implementing Flexible Authentication Strategies in Go: A Real-World Example with External Secrets Operator
2024-12-10T00:00:00+00:00
In modern cloud-native applications, authentication requirements can vary significantly across different environments and use cases. In this post, I’ll share how we implemented a flexible authentication system for a webhook server that integrates with Kubernetes External Secrets Operator (ESO).</p>
The Challenge</h2>
Our webhook server needed to support different authentication methods depending on the deployment environment and security requirements. We wanted to support:</p>

JWT verification with a private key</li>
JWKS-based verification (for Keycloak integration)</li>
Simple shared secret authentication</li>
An untrusted mode for development</li>
</ol>
The Solution: Strategy Pattern</h2>
We decided to use the Strategy pattern to implement our authentication system. This pattern allows us to encapsulate different authentication methods and switch between them easily using environment variables.</p>
Here’s the core interface that defines our authentication strategy:</p>
type</span> AuthStrategy</span> interface</span> {</span></span>
    Authenticate</span>(</span>r</span> *</span>http</span>.</span>Request</span>) (</span>bool</span>,</span> error</span>)</span></span>
}</span></span></code></pre>
This simple interface allows us to implement different authentication methods while keeping the rest of our application code unchanged.</p>
Implementing the Strategies</h2>
1. JWT Private Key Strategy</h3>
This strategy verifies JWTs using a private key stored in our secrets manager:</p>
type</span> JWTPrivateKeyStrategy</span> struct</span> {</span></span>
    secretClient</span> *</span>vsecm</span>.</span>Client</span></span>
}</span></span>
</span>
func</span> (</span>s </span>*</span>JWTPrivateKeyStrategy</span>)</span> Authenticate</span>(</span>r</span> *</span>http</span>.</span>Request</span>) (</span>bool</span>,</span> error</span>) {</span></span>
    privateKey</span>,</span> err</span> :=</span> s</span>.</span>secretClient</span>.</span>FetchPassword</span>("</span>jwt-private-key</span>")</span></span>
    if</span> err</span> !=</span> nil</span> {</span></span>
        return</span> false</span>,</span> fmt</span>.</span>Errorf</span>("</span>failed to fetch private key: </span>%v</span>",</span> err</span>)</span></span>
    }</span></span>
    // JWT verification logic here</span></span>
}</span></span></code></pre>2. JWKS Strategy</h3>
For integration with Keycloak or other OIDC providers, we implemented JWKS-based verification:</p>
type</span> JWKSStrategy</span> struct</span> {</span></span>
    jwksURL</span> string</span></span>
    keySet</span>  jwk</span>.</span>Set</span></span>
}</span></span>
</span>
func</span> (</span>s </span>*</span>JWKSStrategy</span>)</span> Authenticate</span>(</span>r</span> *</span>http</span>.</span>Request</span>) (</span>bool</span>,</span> error</span>) {</span></span>
    // JWKS verification logic here</span></span>
}</span></span></code></pre>
A key advantage of this approach is that we don’t need to store any secrets - we just use the public keys provided by the OIDC provider.</p>
3. Shared Secret Strategy</h3>
For simpler deployments, we implemented a basic shared secret authentication:</p>
type</span> SharedSecretStrategy</span> struct</span> {</span></span>
    secretClient</span> *</span>vsecm</span>.</span>Client</span></span>
}</span></span>
</span>
func</span> (</span>s </span>*</span>SharedSecretStrategy</span>)</span> Authenticate</span>(</span>r</span> *</span>http</span>.</span>Request</span>) (</span>bool</span>,</span> error</span>) {</span></span>
    secret</span>,</span> err</span> :=</span> s</span>.</span>secretClient</span>.</span>FetchPassword</span>("</span>shared-secret</span>")</span></span>
    if</span> err</span> !=</span> nil</span> {</span></span>
        return</span> false</span>,</span> fmt</span>.</span>Errorf</span>("</span>failed to fetch shared secret: </span>%v</span>",</span> err</span>)</span></span>
    }</span></span>
    // Secret comparison logic here</span></span>
}</span></span></code></pre>4. Untrusted Strategy (Development Mode)</h3>
For development environments, we have a strategy that bypasses authentication:</p>
type</span> UntrustedStrategy</span> struct</span>{}</span></span>
</span>
func</span> (</span>s </span>*</span>UntrustedStrategy</span>)</span> Authenticate</span>(</span>r</span> *</span>http</span>.</span>Request</span>) (</span>bool</span>,</span> error</span>) {</span></span>
    return</span> true</span>,</span> nil</span></span>
}</span></span></code></pre>Switching Between Strategies</h2>
The magic happens in our strategy factory:</p>
func</span> getAuthStrategy</span>()</span> AuthStrategy</span> {</span></span>
    strategy</span> :=</span> os</span>.</span>Getenv</span>("</span>AUTH_STRATEGY</span>")</span></span>
    switch</span> strategy</span> {</span></span>
    case</span> "</span>jwt_private_key</span>":</span></span>
        return</span> &</span>JWTPrivateKeyStrategy</span>{}</span></span>
    case</span> "</span>jwks</span>":</span></span>
        return</span> &</span>JWKSStrategy</span>{}</span></span>
    case</span> "</span>shared_secret</span>":</span></span>
        return</span> &</span>SharedSecretStrategy</span>{}</span></span>
    case</span> "</span>untrusted</span>":</span></span>
        return</span> &</span>UntrustedStrategy</span>{}</span></span>
    default</span>:</span></span>
        panic</span>(</span>fmt</span>.</span>Sprintf</span>("</span>Unknown auth strategy: </span>%s</span>",</span> strategy</span>))</span></span>
    }</span></span>
}</span></span></code></pre>Using the Authentication System</h2>
The authentication system is implemented as middleware:</p>
func</span> authMiddleware</span>(</span>next</span> http</span>.</span>HandlerFunc</span>)</span> http</span>.</span>HandlerFunc</span> {</span></span>
    strategy</span> :=</span> getAuthStrategy</span>()</span></span>
    return func</span>(</span>w</span> http</span>.</span>ResponseWriter</span>,</span> r</span> *</span>http</span>.</span>Request</span>) {</span></span>
        authenticated</span>,</span> err</span> :=</span> strategy</span>.</span>Authenticate</span>(</span>r</span>)</span></span>
        if</span> err</span> !=</span> nil</span> {</span></span>
            http</span>.</span>Error</span>(</span>w</span>,</span> fmt</span>.</span>Sprintf</span>("</span>Authentication error: </span>%v</span>",</span> err</span>),</span> </span></span>
                      http</span>.</span>StatusInternalServerError</span>)</span></span>
            return</span></span>
        }</span></span>
        if !</span>authenticated</span> {</span></span>
            http</span>.</span>Error</span>(</span>w</span>, "</span>Unauthorized</span>",</span> http</span>.</span>StatusUnauthorized</span>)</span></span>
            return</span></span>
        }</span></span>
        next</span>.</span>ServeHTTP</span>(</span>w</span>,</span> r</span>)</span></span>
    }</span></span>
}</span></span></code></pre>Benefits of This Approach</h2>

Flexibility</strong>: Easy to switch between authentication methods using environment variables.</li>
Maintainability</strong>: Each authentication strategy is isolated in its own type.</li>
Extensibility</strong>: New authentication methods can be added without changing existing code.</li>
Security</strong>: Proper separation of concerns and integration with secrets management.</li>
Developer Experience</strong>: Easy to use development mode without compromising production security.</li>
</ol>
Real-World Usage</h2>
In our case, we’re using this system with the External Secrets Operator webhook. Here’s how we configure it in different environments:</p>

Production</strong>: AUTH_STRATEGY=jwks</code> for integration with Keycloak</li>
Staging</strong>: AUTH_STRATEGY=jwt_private_key</code> for testing with our own JWT implementation</li>
Development</strong>: AUTH_STRATEGY=untrusted</code> for rapid development</li>
</ul>
Lessons Learned</h2>

Start Simple</strong>: Begin with the simplest strategy that meets your needs.</li>
Plan for Change</strong>: The Strategy pattern makes it easy to evolve your authentication system.</li>
Security First</strong>: Even in development, have a clear path to production-grade security.</li>
Configuration Matters</strong>: Environment-based configuration provides flexibility without complexity.</li>
</ol>
Conclusion</h2>
Building a flexible authentication system doesn’t have to be complicated. By using the Strategy pattern and good design principles, we created a system that’s both secure and adaptable to different environments and requirements.</p>
Remember: security is not one-size-fits-all. The ability to adapt your authentication strategy to different environments and requirements is crucial for modern cloud-native applications.</p>


Building a Secure Secrets Management Server in Go
2024-12-10T00:00:00+00:00
In modern cloud-native environments, managing secrets securely is crucial for maintaining the security of your infrastructure. This post walks through building a secure secrets management server in Go that handles TLS certificates and serves secrets via a REST API.</p>
Overview</h2>
Our server needs to:</p>

Fetch secrets from a secrets manager</li>
Set up a TLS-enabled HTTP server</li>
Serve specific secrets based on API requests</li>
Handle secret paths and implement access control</li>
</ol>
Implementation Details</h2>
Secret Types and Storage</h3>
The server handles two main types of secrets:</p>


Infrastructure secrets (prefixed with raw:vsecm-scout</code>)</p>

TLS certificates and keys</li>
JWT signing keys</li>
Other infrastructure-related secrets</li>
</ul>
</li>

Application secrets (other raw:</code> prefixed secrets)</p>

Stored in a map for serving via the API</li>
Can be accessed using path-based queries</li>
</ul>
</li>
</ol>
Here’s how we organize these secrets:</p>
var</span> (</span></span>
    jwtSecret</span>      string</span></span>
    secretsToServe</span> map</span>[</span>string</span>]</span>string</span></span>
)</span></span></code></pre>Fetching and Processing Secrets</h3>
The server starts by fetching secrets from the secrets manager:</p>
sfr</span>,</span> err</span> :=</span> sentry</span>.</span>Fetch</span>()</span></span>
if</span> err</span> !=</span> nil</span> {</span></span>
    log</span>.</span>Fatalf</span>("</span>Error fetching secrets: </span>%v</span>",</span> err</span>)</span></span>
}</span></span></code></pre>
It then processes these secrets, organizing them based on their prefix:</p>
for</span> _</span>,</span> secret</span> :=</span> range</span> secrets</span> {</span></span>
    name</span> :=</span> secret</span>["</span>Name</span>"].(</span>string</span>)</span></span>
    value</span> :=</span> secret</span>["</span>value</span>"].(</span>string</span>)</span></span>
</span>
    switch</span> name</span> {</span></span>
    case</span> "</span>raw:vsecm-scout-jwt-secret</span>":</span></span>
        jwtSecret</span> =</span> value</span></span>
    case</span> "</span>raw:vsecm-scout-crt</span>":</span></span>
        serverCert</span> =</span> value</span></span>
    // ... other cases</span></span>
    default</span>:</span></span>
        if</span> strings</span>.</span>HasPrefix</span>(</span>name</span>, "</span>raw:</span>")</span> && !</span>strings</span>.</span>HasPrefix</span>(</span>name</span>, "</span>raw:vsecm-scout</span>") {</span></span>
            secretsToServe</span>[</span>strings</span>.</span>TrimPrefix</span>(</span>name</span>, "</span>raw:</span>")]</span> =</span> value</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>TLS Configuration</h3>
Security is paramount for a secrets management server. We use TLS to encrypt all communications:</p>
cert</span>,</span> err</span> :=</span> tls</span>.</span>X509KeyPair</span>([]</span>byte</span>(</span>serverCert</span>), []</span>byte</span>(</span>serverKey</span>))</span></span>
if</span> err</span> !=</span> nil</span> {</span></span>
    log</span>.</span>Fatalf</span>("</span>Error loading server certificate and key: </span>%v</span>",</span> err</span>)</span></span>
}</span></span>
</span>
tlsConfig</span> := &</span>tls</span>.</span>Config</span>{</span></span>
    Certificates</span>: []</span>tls</span>.</span>Certificate</span>{</span>cert</span>},</span></span>
}</span></span>
</span>
server</span> := &</span>http</span>.</span>Server</span>{</span></span>
    Addr</span>:      "</span>:8443</span>",</span></span>
    TLSConfig</span>:</span> tlsConfig</span>,</span></span>
}</span></span></code></pre>API Implementation</h3>
The server exposes a webhook endpoint that serves secrets based on a key and path:</p>
func</span> webhookHandler</span>(</span>w</span> http</span>.</span>ResponseWriter</span>,</span> r</span> *</span>http</span>.</span>Request</span>) {</span></span>
    // ... request validation ...</span></span>
</span>
    key</span> :=</span> values</span>.</span>Get</span>("</span>key</span>")</span></span>
    path</span> :=</span> values</span>.</span>Get</span>("</span>path</span>")</span></span>
</span>
    secretValue</span>,</span> exists</span> :=</span> secretsToServe</span>[</span>key</span>]</span></span>
    if !</span>exists</span> {</span></span>
        http</span>.</span>Error</span>(</span>w</span>, "</span>Invalid key</span>",</span> http</span>.</span>StatusUnauthorized</span>)</span></span>
        return</span></span>
    }</span></span>
</span>
    // ... process and return the secret ...</span></span>
}</span></span></code></pre>Path-Based Secret Access</h3>
The server implements a flexible path-based access system for secrets:</p>
func</span> getValueFromPath</span>(</span>data interface</span>{},</span> path</span> string</span>) (</span>interface</span>{},</span> error</span>) {</span></span>
    parts</span> :=</span> strings</span>.</span>Split</span>(</span>path</span>, "</span>.</span>")</span></span>
</span>
    var</span> current</span> =</span> data</span></span>
    for</span> _</span>,</span> part</span> :=</span> range</span> parts</span> {</span></span>
        switch</span> v</span> :=</span> current</span>.(</span>type</span>) {</span></span>
        case map</span>[</span>string</span>]</span>interface</span>{}:</span></span>
            if</span> val</span>,</span> ok</span> :=</span> v</span>[</span>part</span>];</span> ok</span> {</span></span>
                current</span> =</span> val</span></span>
            }</span> else</span> {</span></span>
                return</span> nil</span>,</span> fmt</span>.</span>Errorf</span>("</span>key not found: </span>%s</span>",</span> part</span>)</span></span>
            }</span></span>
        // ... handle other cases ...</span></span>
        }</span></span>
    }</span></span>
</span>
    return</span> current</span>,</span> nil</span></span>
}</span></span></code></pre>
This allows clients to access nested values within secrets using dot notation (e.g., “namespaces.cokeSystem.secrets.adminCredentials”).</p>
Security Considerations</h2>

TLS</strong>: All communications are encrypted using TLS.</li>
Access Control</strong>: Secrets are only served to clients with valid keys.</li>
Path Validation</strong>: The server validates all path requests to prevent unauthorized access.</li>
Error Handling</strong>: Careful error handling prevents information leakage.</li>
</ol>
Usage Example</h2>
To request a secret, clients make a GET request to the webhook endpoint:</p>
curl</span> -k</span> "</span>https://localhost:8443/webhook?key=key=coca-cola.cluster-001&path=namespaces.cokeSystem.secrets.adminCredentials</span>"</span></span></code></pre>
The server will return the requested secret value if the key is valid and the path exists.</p>
Future Improvements</h2>

JWT Validation</strong>: Implement JWT-based authentication using the stored JWT secret.</li>
Rate Limiting</strong>: Add rate limiting to prevent brute force attacks.</li>
Audit Logging</strong>: Implement detailed audit logging for all secret access.</li>
Secret Rotation</strong>: Add support for automatic secret rotation.</li>
Metrics</strong>: Add Prometheus metrics for monitoring.</li>
</ol>
Conclusion</h2>
Building a secure secrets management server requires careful attention to security details and proper handling of sensitive data. This implementation provides a solid foundation that can be extended based on specific requirements.</p>
Remember that this is just one piece of a larger secrets management strategy. It should be combined with other security practices like:</p>

Regular secret rotation</li>
Strict access controls</li>
Comprehensive audit logging</li>
Network security controls</li>
Regular security audits</li>
</ul>
The complete code provides a secure and flexible solution for serving secrets in a cloud-native environment while maintaining security best practices.</p>


Cross-Compiling Go Applications on M3 Macs: A Practical Guide
2024-11-27T00:00:00+00:00
Cross-compiling Go applications on Apple Silicon (M-series) Macs can be tricky, especially when dealing with CGO dependencies. In this guide, we’ll explore different approaches to building Go applications for multiple architectures, specifically targeting Linux (AMD64 and ARM64) and macOS (ARM64).</p>
The Challenge</h2>
When working with Go applications that use CGO, simple cross-compilation commands like GOOS=linux GOARCH=amd64 go build</code> might not be sufficient. This is particularly true when:</p>

Your application uses CGO-dependent packages</li>
You need to build for multiple architectures</li>
You’re working on an M-series Mac</li>
</ul>
Initial Approach: Local Cross-Compilation</h2>
My first attempt involved using traditional cross-compilation tools. Here’s what I initially tried:</p>
# Linux ARM64</span></span>
CGO_ENABLED</span>=</span>0</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> keeper ./app/keeper/cmd/main.go</span></span>
CGO_ENABLED</span>=</span>1</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> nexus ./app/nexus/cmd/main.go</span></span>
CGO_ENABLED</span>=</span>0</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> spike ./app/spike/cmd/main.go</span></span></code></pre>
However, when trying to cross-compile for different architectures, I ran into issues:</p>
GOOS</span>=</span>linux</span> GOARCH</span>=</span>amd64</span> CGO_ENABLED</span>=</span>1</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> nexus-linux-amd64 ./app/nexus/cmd/main.go</span></span></code></pre>
This approach failed because it needed proper cross-compilation toolchains.</p>
The Solution: Docker-Based Cross-Compilation</h2>
After exploring various options, I found that using Docker for cross-compilation provides the most reliable and reproducible solution. Here’s how to implement it:</p>

First, create a Dockerfile:</li>
</ol>
FROM</span> golang:1.21-alpine </span>AS</span> builder</span></span>
</span>
# Install build tools</span></span>
RUN</span> apk add --no-cache gcc musl-dev</span></span>
</span>
# Set working directory</span></span>
WORKDIR</span> /app</span></span>
</span>
# Copy go mod files</span></span>
COPY</span> go.mod go.sum ./</span></span>
RUN</span> go mod download</span></span>
</span>
# Copy source code</span></span>
COPY</span> . .</span></span>
</span>
# Build for different platforms</span></span>
RUN</span> GOOS=linux GOARCH=amd64 CGO_ENABLED=0 GOEXPERIMENT=boringcrypto go build -o keeper-linux-amd64 ./app/keeper/cmd/main.go && \</span></span>
    GOOS=linux GOARCH=amd64 CGO_ENABLED=1 GOEXPERIMENT=boringcrypto go build -o nexus-linux-amd64 ./app/nexus/cmd/main.go && \</span></span>
    GOOS=linux GOARCH=amd64 CGO_ENABLED=0 GOEXPERIMENT=boringcrypto go build -o spike-linux-amd64 ./app/spike/cmd/main.go && \</span></span>
    GOOS=linux GOARCH=arm64 CGO_ENABLED=0 GOEXPERIMENT=boringcrypto go build -o keeper-linux-arm64 ./app/keeper/cmd/main.go && \</span></span>
    GOOS=linux GOARCH=arm64 CGO_ENABLED=1 GOEXPERIMENT=boringcrypto go build -o nexus-linux-arm64 ./app/nexus/cmd/main.go && \</span></span>
    GOOS=linux GOARCH=arm64 CGO_ENABLED=0 GOEXPERIMENT=boringcrypto go build -o spike-linux-arm64 ./app/spike/cmd/main.go</span></span></code></pre>

Create a build script:</li>
</ol>
#!/bin/bash</span></span>
</span>
# Build the Docker image</span></span>
docker</span> build</span> -t</span> go-cross-compiler .</span></span>
</span>
# Create a container and copy the binaries</span></span>
docker</span> create</span> --name</span> temp-container go-cross-compiler</span></span>
docker</span> cp temp-container:/app/keeper-linux-amd64 .</span></span>
docker</span> cp temp-container:/app/nexus-linux-amd64 .</span></span>
docker</span> cp temp-container:/app/spike-linux-amd64 .</span></span>
docker</span> cp temp-container:/app/keeper-linux-arm64 .</span></span>
docker</span> cp temp-container:/app/nexus-linux-arm64 .</span></span>
docker</span> cp temp-container:/app/spike-linux-arm64 .</span></span>
</span>
# Clean up</span></span>
docker</span> rm temp-container</span></span></code></pre>Advantages of the Docker Approach</h2>

Reproducibility</strong>: The build environment is consistent across different development machines</li>
No Local Dependencies</strong>: No need to install cross-compilation tools locally</li>
Simplified Process</strong>: One command builds all targets</li>
Consistent Results</strong>: Binaries are built in a controlled environment</li>
Easy CI/CD Integration</strong>: The Docker-based approach works well in automated pipelines</li>
</ol>
Building for macOS ARM64</h2>
For macOS ARM64 builds, you can still build natively on your M-series Mac:</p>
GOOS</span>=</span>darwin</span> GOARCH</span>=</span>arm64</span> CGO_ENABLED</span>=</span>0</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> keeper-darwin-arm64 ./app/keeper/cmd/main.go</span></span>
GOOS</span>=</span>darwin</span> GOARCH</span>=</span>arm64</span> CGO_ENABLED</span>=</span>1</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> nexus-darwin-arm64 ./app/nexus/cmd/main.go</span></span>
GOOS</span>=</span>darwin</span> GOARCH</span>=</span>arm64</span> CGO_ENABLED</span>=</span>0</span> GOEXPERIMENT</span>=</span>boringcrypto</span> go</span> build</span> -o</span> spike-darwin-arm64 ./app/spike/cmd/main.go</span></span></code></pre>Common Pitfalls and Solutions</h2>

CGO Dependencies</strong>: When CGO_ENABLED=1</code>, ensure your Docker container has the necessary build tools installed</li>
Architecture Mismatch</strong>: Double-check GOOS</code> and GOARCH</code> values match your target platforms</li>
Build Tags</strong>: Consider using build tags for platform-specific code</li>
Static Linking</strong>: For better portability, use CGO_ENABLED=0</code> when possible</li>
</ol>
Conclusion</h2>
While cross-compilation on M-series Macs presents some challenges, using Docker provides a robust and maintainable solution. This approach simplifies the build process and ensures consistent results across different architectures.</p>
For projects that don’t require CGO, you might still use direct cross-compilation. However, for complex projects with CGO dependencies, the Docker-based approach is recommended.</p>
Remember to version your build scripts and Dockerfile alongside your project code to maintain build reproducibility across your team.</p>


Keep Your Secrets... Secret: Introducing VMware Secrets Manager
2023-08-16T00:00:00+00:00
</p>
In the ever-evolving landscape of cloud-native applications, secrets management
is critical to ensuring sensitive information’s security and integrity. While
several solutions are available, the recent shift in HashiCorp’s licensing
towards a Business Source License (BSL) has raised concerns and sparked
discussions within the community.</p>
As the lead architect of VMware Secrets Manager</strong> (VSecM</em></strong>)</a>,
I’d like to take this opportunity to introduce our solution, which offers a robust,
flexible, and permissive</strong> alternative to HashiCorp’s Vault.</p>

⭐️ Star Us on GitHub ⭐️</strong></p>
If you find value in our approach and want to help others discover this
outstanding technology, star our GitHub
repository</strong></a>. Your support helps
increase visibility and encourages more collaboration and innovation within the
community.</p>
</blockquote>
A New Licensing Landscape</h2>
HashiCorp’s decision to adopt a Business Source License has been viewed by some
as a restrictive move. The BSL, unlike open-source licenses, imposes certain
limitations and conditions that may not align with the needs and values of all
organizations and developers.</p>
In contrast, VMware Secrets Manager</strong></a> is licensed under
the BSD 2-Clause License, a permissive open-source license that encourages
collaboration, innovation, and freedom of use.</p>
VMware Secrets Manager: A Closer Look</h2>
VSecM</strong> is designed with modern developers and DevOps professionals in mind.
Here’s why it stands out:</p>

Ease of Use</strong>: With a Quickstart Guide</strong></a>,
intuitive CLI</strong></a>, and developer-friendly
SDK</strong></a>, VSecM</strong> simplifies secrets management
without compromising security.</li>
Kubernetes Is a First-Class Citizen</strong>: VSecM</strong> seamlessly integrates with
Kubernetes, leveraging SPIRE</strong></a>
for authentication and offering flexible secret storage and transformation
options.</li>
Community Engagement</strong>: We believe in open collaboration and
community-driven development. Our Contributing Guide</strong></a>
invites developers to get involved, ask questions, and contribute to the project.</li>
Secure by Default</strong>: VSecM</strong> offers advanced security features, including
encryption, manual master secret setting, and integration with various backing
stores.</li>
</ul>
Join the Future of Secrets Management</h2>
VMware Secrets Manager</strong> is more than just a tool; it’s a community-driven
project that aims to redefine secrets management in a cloud-native world. We
invite you to explore VSecM</strong>, contribute to its growth, and join us in
shaping the future of secure and resilient applications.</p>
Whether you’re a developer looking to contribute or an organization seeking a
flexible and secure solution for secrets management, VSecM</strong> offers a
welcoming and innovative platform.</p>
This is Just the Beginning: A Vision for the Future</h3>
At VMware Secrets Manager</strong>, we believe in continuous innovation and growth.
Our roadmap</strong></a> is a testament to our
commitment to delivering cutting-edge solutions that meet the evolving needs of
the cloud-native community.</p>
Here’s a glimpse of what’s on the horizon:</p>

Stability and Usability Enhancements</strong>: Upcoming releases focus on improving
stability, documentation, build automation, and overall user experience.</li>
Innovative Features</strong>: From Secretless VSecM to machine-readable logs,
performance improvements, and large-scale secret ingestion, we’re pushing the
boundaries of what’s possible in secrets management.</li>
Integration and Compatibility</strong>: Future iterations include integration with
AWS KMS, Azure Key Vault, Google Cloud KMS, and even HashiCorp Vault,
expanding the reach and compatibility of VSecM.</li>
Community Development and Collaboration</strong>: We’re investing in community
development efforts, multi-cluster secret federation, and creating
abstractions to make cloud integrations easier.</li>
</ul>
Our roadmap is not just a plan; it’s a promise to our users and contributors
that we have a lot planned for the future of VMware Secrets Manager. We’re
excited about the journey ahead and invite you to be a part of it.</p>

⭐️ Star Us on GitHub ⭐️</strong></p>
If you find value in our approach and want to help others discover this
outstanding technology, star our GitHub repository</strong></a>.
Your support helps increase visibility and encourages more collaboration and
innovation within the community.</p>
</blockquote>
Help Us Shape the Future</h3>
Start your journey with VMware Secrets Manager today</strong></a>
and unlock the potential of cloud-native secrets management.</p>

Section Contents</h2>


Old Man Yelling at the Corpus</a></p>
</li>

Closure</a></p>
</li>

Consume Less</a></p>
</li>

▶ Catch 22</strong></p>
</li>

Embracing Simplicity: Why I’ve Given Up on Smart Quotes and Other Typographic Niceties</a></p>
</li>

Transform Feedback into Professional Mastery</a></p>
</li>

Trust Cultivates a Cohesive Team</a></p>
</li>

Psst… You Don’t Have to Use Medium</a></p>
</li>

The New Zero to Hero Design</a></p>
</li>

Build Strong Connections to Land Your Dream Job</a></p>
</li>

Keep Your Secrets… Secret</a></p>
</li>

Long Live Aegis!</a></p>
</li>

Write to Forget</a></p>
</li>

Craft Captivating Documentation</a></p>
</li>

Reshape Your Workspace, Reshape Your Future</a></p>
</li>

Secrets</a></p>
</li>

‘Later’ Does Not Exist</a></p>
</li>

Embracing Daily Reflection</a></p>
</li>
</ul>


Long Live Aegis!
2023-08-03T00:00:00+00:00
</p>
Dear community,</p>
I am thrilled to share an update with all of you. Aegis</strong> has transformed and
landed into its new home! It is now entering a phase as **VMware Secrets Manager
** for Cloud-Native workloads!</p>
Please learn more about our project in the repository
following this link</a>.</p>
Also, stay updated with us on our website at vsecm.com</strong></a>.</p>
Coming Up Next</h2>
This change represents more than just a new name. It symbolizes our unwavering
dedication to pushing boundaries, fostering innovation, and delivering reliable
solutions for your cloud-native workloads.</p>
As things settle down, we’re already busy planning our steps. You can keep track
of our progress.</p>
Follow our plans in our roadmap page</a>.</p>
We aim to provide how the project will proceed as transparently as possible. Of
course, our contribution cadence and frequency depend on the availability and
commitment of our core contributors.</p>
Stronger Together</h2>
While Aegis has served us well, VMware Secrets Manager</strong> under VMware Tanzu
GitHub organization opens up possibilities. It brings us closer to fulfilling
our promise of offering you an efficient, secure, and cutting-edge cloud-native
Secrets Management solution.</p>
We are thrilled about this chapter and eagerly anticipate serving you, our
community, as we move forward. Your contributions and feedback mean the world to
us.</p>
Who Else Wants to Contribute?</h2>
Feel free to reach out if you’re interested in contributing to VMware Secrets
Manager</strong></a>.</p>
Stay tuned for updates and developments as we continue on this journey.</p>
Thank you very much for your support!</p>
Turtle power 🐢⚡️.</p>

Section Contents</h2>


Old Man Yelling at the Corpus</a></p>
</li>

Closure</a></p>
</li>

Consume Less</a></p>
</li>

Catch 22</a></p>
</li>

Embracing Simplicity: Why I’ve Given Up on Smart Quotes and Other Typographic Niceties</a></p>
</li>

Transform Feedback into Professional Mastery</a></p>
</li>

Trust Cultivates a Cohesive Team</a></p>
</li>

Psst… You Don’t Have to Use Medium</a></p>
</li>

The New Zero to Hero Design</a></p>
</li>

Build Strong Connections to Land Your Dream Job</a></p>
</li>

Keep Your Secrets… Secret</a></p>
</li>

Long Live Aegis!</a></p>
</li>

▶ Write to Forget</strong></p>
</li>

Craft Captivating Documentation</a></p>
</li>

Reshape Your Workspace, Reshape Your Future</a></p>
</li>

Secrets</a></p>
</li>

‘Later’ Does Not Exist</a></p>
</li>

Embracing Daily Reflection</a></p>
</li>
</ul>


Unlock Your True Potential: Make Your Hard Work Visible
2023-01-16T00:00:00+00:00
</p>


    </p>
    
Show yourself.</p>
</div>

Update 2024-05-21</strong></p>
Aegis</strong> is now maintained by VMware Tanzu</strong> GitHub Organization
with a new name: VMware Secrets Manager</a></strong>.</p>
It is ready for production use, and as the time of this writing we
are already using it in production clusters.</p>
</blockquote>
Welcome to the 25th issue of Zero to Hero</strong> Highlights.</p>
Several things have been going on, yet I think this week’s highlight was
Aegis</strong></a>. It has been very well received by people who
are well-known in the Cloud Native security community, and I have a feeling it
is growing to become a bit more than a side project, but we’ll see.</p>
Aegis: Keep Your Secrets… Secret</h2>
As I said, last week was mainly about Aegis</strong>, but what is Aegis</strong>?</p>
Aegis</strong></a> is a Kubernetes-native, lightweight secrets management
solution that keeps your secrets secret. And last week, I made significant
progress with it.</p>
Some key highlights of the current version are:</p>

Upgraded Aegis</strong> to the latest and greatest SPIRE</strong></a>
version as the identity control plane. That gave a bunch of stability
improvements and reduced memory usage significantly.</li>
A lot of documentation updates to make Aegis</strong> easier to use and deploy.</li>
Making everything configurable via environment variables.</li>
Added liveness</strong> and readiness</strong> probes to critical components for
Kubernetes-native lifecycle management.</li>
Started using distroless images</strong></a>
for an additional layer of security.</li>
Using SPIFFE CSI driver</strong></a> instead of
volume mounts (for security again</em>).</li>
</ul>
Although Aegis</strong> is still an alpha product and has yet to be battle-tested,
I am confident it can be used in a production cluster.</p>
Random Thought of the Week</h2>
In today’s fast-paced and competitive business environment, it is essential to
stand out and make your hard work and achievements visible to your management.
Unfortunately, you can fall into the trap of being overlooked as a hidden gem
among your peers, despite your consistent efforts and contributions to the team.</p>
This can be detrimental to career growth and advancement opportunities. So what
are the ways to sort this out, unlock your true potential, and ace your career?</p>
One word: Take initiative</strong>… Okay, that was two words, but still 🙂.</p>
By sharing your daily progress, goals, and accomplishments with your manager,
you can ensure that your hard work does not go unnoticed.</p>
One effective way to make your work visible is by providing regular updates</strong>
and participating in huddles with your manager. This allows you to share your
progress on current projects, any challenges you may be facing, and any new
ideas or solutions you have come up with.</p>
By providing this information regularly, you can create a transparent view of
your work for your manager and demonstrate your willingness to actively
collaborate and contribute to the team.</p>
Another critical aspect of making your work visible is sharing real-time metrics
and key performance indicators (KPIs</em></strong>) with your manager. These metrics
provide valuable insights into the impact and results of your work and
demonstrate your ability to measure and track your progress. This can help your
manager better understand the value you bring to the team and your role in
achieving business goals.</p>
In addition to regular updates and sharing metrics, it is also essential to
proactively</strong> offer creative solutions</strong>, volunteer extra time and effort,
and showcase your skill set to help your manager tackle challenges. This
demonstrates your willingness to go above and beyond and showcases your ability
to think outside the box and bring fresh perspectives to the team.</p>
All these can put you on your manager’s radar as a valuable asset to the team
and help you get the promotion you deserve.</p>
Look What I’ve Found</h2>
Here are the things that grabbed my attention this week.</p>
I typically don’t share these anywhere else.</p>
Exclusively hand-picked for you 👌. Enjoy.</p>

Sampler is a tool for shell commands execution, visualization and
alerting</a>.</li>
Airplane is a developer infrastructure for internal tooling</a>.</li>
In case you wonder how a unix kernel runs a program, here is a nice
article about it</a>.</li>
</ul>
Thanks a Lot ❤️</h2>
That’s all for this week. Next week, I’ll gather more unique content and
resources.</p>
So, until next time… May the source be with you 🦄.</p>

Issues</h2>


Issue 1: Hello World, Hello Stars, Hello Universe</a></p>
</li>

Issue 2: The Only Thing That doesn’t Change is Change Itself</a></p>
</li>

Issue 3: Know Thyself</a></p>
</li>

Issue 4: Have You Fizzed that Buzz?</a></p>
</li>

Issue 5: Be Kind</a></p>
</li>

Issue 6: Earn the Promotion You Deserve</a></p>
</li>

Issue 7: Who Else Journals Daily?</a></p>
</li>

Issue 8: Who Are You?</a></p>
</li>

Issue 9: How to Make Yourself Heard</a></p>
</li>

Issue 10: Tough Conversations</a></p>
</li>

Issue 11: Assemble Your Personal Board of Advisor</a></p>
</li>

Issue 12: What’s Your Plan</a></p>
</li>

Issue 13: Nine-to-Five? I Don’t Think So</a></p>
</li>

Issue 14: Respect and Understanding</a></p>
</li>

Issue 15: Pivoting Your Career?</a></p>
</li>

Issue 16: Ghosted?</a></p>
</li>

Issue 17: ‘Following Your Passion’ Is Hardly Enough</a></p>
</li>

Issue 18: Keep Cam and Carry On</a></p>
</li>

Issue 19: Attention, Intention, Compassion</a></p>
</li>

Issue 20: Words Matter</a></p>
</li>

Issue 21: Change Is the Only Constant</a></p>
</li>

Issue 22: Overcome the Awkward Feeling of Networking</a></p>
</li>

Issue 23: Unleash Your Curiosity: Unlock Your Potential as a Leader</a></p>
</li>

Issue 24: Interview Done. Radio Silence 🎃 What Now?</a></p>
</li>

▶ Issue 25: Unlock Your True Potential: Make Your Hard Work Visible</strong></p>
</li>

Issue 26: Winning at Work: Thriving With Difficult Colleagues</a></p>
</li>

Issue 27: Promotions Don’t Happen Overnight</a></p>
</li>
</ul>


Zero to Prod in Half an Hour: Part 1 --- An Overview of FizzBuzz Pro
2022-10-15T00:00:00+00:00

    </p>
    
Zero to Prod in Half an Hour: Part 1 --- An Overview of FizzBuzz Pro</p>
</div>
This series will show how you can deploy a full-blown production-ready web
application in half an hour. Let’s look into what kind of an application we’ll
build and what technologies we’ll use.</p>
Lecture</h2>

  </iframe>
</div>
Zero to Prod in Half an Hour: Part 1 --- An Overview of FizzBuzz Pro</p>

Playlist</h2>


▶ Part 1: An Overview of FizzBuzz Pro</strong></p>
</li>

Part 2: Generating Static HTML</a></p>
</li>

Part 3: Mutating the Generated HTML Files</a></p>
</li>

Part 4: App Authentication Overview</a></p>
</li>

Part 5: Implementing an OIDC Authenticator</a></p>
</li>

Part 6: Serving Web Pages</a></p>
</li>

Part 7: A Mild Introduction to Middlewares</a></p>
</li>

Part 8: Authenticate All the Things</a></p>
</li>

Part 9: Thinking in Middlewares</a></p>
</li>

Part 10: Authentication and Subscription Middlewares</a></p>
</li>

Part 11: Implementing Authentication Handlers</a></p>
</li>

Part 12: The Final Touches</a></p>
</li>

Part 13: Containerizing Our Application</a></p>
</li>

Part 14: Onwards to Kubernetes</a></p>
</li>

Creating ECR Repositories</a></p>
</li>

Deploying a Microservice to Kubernetes</a></p>
</li>

Fizz that Buzz</a></p>
</li>

FizzBuzz Pro High-Level Design</a></p>
</li>

FizzBuzz Pro Repositories</a></p>
</li>
</ul>
Tools and Technologies Mentioned</h2>
Here are the tools and technologies that were mentioned in the video, along with
related articles and other helpful links.</p>

Python Pygments</a></li>
Python Pygments CLI</a></li>
Docker</a></li>
Dockerfile</a></li>
Container Runtimes</a></li>
Kubernetes</a></li>
MongoDB</a></li>
MongoDB Atlas</a></li>
Papertrail</a></li>
Gumroad</a></li>
Gumroad API</a></li>
Go Programming Language</a></li>
Gin Web Framework</a></li>
Amazon EKS</a></li>
Amazon ECR</a></li>
Amazon S3</a></li>
Amazon Route53</a></li>
Elastic Load Balancing</a></li>
Amazon Cloudfront</a></li>
</ul>
Read The Source</h2>

Download the source code (114kb zip
archive</em>)</a></li>
</ul>

Until the next lecture… May the source be with you 🦄.</p>


mTLS With SPIRE: Part 5: Containerizing the Client App
2022-08-19T00:00:00+00:00

    </p>
    
mTLS With SPIRE: Part 5: Containerizing the Client App</p>
</div>
We’ll continue creating creating container images and deploying the client app
to the cluster too, then observe how the client and server communicate with each
other within the pods.</p>

  </iframe>
</div>
mTLS With SPIRE: Part 5: Containerizing the Client</p>

Playlist</h2>


mTLS With SPIRE: Part 1: Introduction</a></p>
</li>

mTLS With SPIRE: Part 2: Creating the Server App</a></p>
</li>

mTLS With SPIRE: Part 3: Creating the Client App</a></p>
</li>

mTLS With SPIRE: Part 4: Containerizing the Server App</a></p>
</li>

▶ mTLS With SPIRE: Part 5: Containerizing the Client App</strong></p>
</li>

mTLS With SPIRE: Part 6: Rolling Out SPIRE to the Cluster</a></p>
</li>

mTLS With SPIRE: Part 7: Registering Nodes and Workloads to SPIRE</a></p>
</li>

mTLS With SPIRE: Part 8: Configuring the Server to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 9: Configuring the Client to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 10: Establishing Cross-Cluster mTLS</a></p>
</li>
</ul>
Read the Source</h2>

Access the source code and other related assets from Zero to Hero</strong> GitHub</a>.</li>
</ul>


mTLS With SPIRE: Part 4: Containerizing the Server Appp
2022-08-19T00:00:00+00:00

    </p>
    
mTLS With SPIRE: Part 4: Containerizing the Server App</p>
</div>
This section will bundle the server application, create and image out of it,
create deployment manifests, and deploy it into the cluster.</p>

  </iframe>
</div>
mTLS With SPIRE: Part 4: Containerizing the Server App</p>

Playlist</h2>


mTLS With SPIRE: Part 1: Introduction</a></p>
</li>

mTLS With SPIRE: Part 2: Creating the Server App</a></p>
</li>

mTLS With SPIRE: Part 3: Creating the Client App</a></p>
</li>

▶ mTLS With SPIRE: Part 4: Containerizing the Server App</strong></p>
</li>

mTLS With SPIRE: Part 5: Containerizing the Client App</a></p>
</li>

mTLS With SPIRE: Part 6: Rolling Out SPIRE to the Cluster</a></p>
</li>

mTLS With SPIRE: Part 7: Registering Nodes and Workloads to SPIRE</a></p>
</li>

mTLS With SPIRE: Part 8: Configuring the Server to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 9: Configuring the Client to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 10: Establishing Cross-Cluster mTLS</a></p>
</li>
</ul>
Tools and Technologies Mentioned</h2>
Here are the tools and technologies that were mentioned in the video, along with
related articles and other helpful links.</p>

Docker</strong></a></li>
Open Container Initiative (OCI</em></strong>)</a></li>
Multistage Builds</a></li>
Dockerfile Reference</a></li>
Distroless Container Images</a></li>
Docker Registry</a></li>
Deployments</a></li>
Services</a></li>
MetalLB</strong></a> (this is the LoadBalancer we used
in this video series</em>)</li>
</ul>
Read the Source</h2>

Access the source code and other related assets from Zero to Hero</strong> GitHub</a>.</li>
</ul>


Zero to Prod in Half an Hour: Part 13 --- Containerizing Our Application
2022-02-10T00:00:00+00:00

    </p>
    
Zero to Prod in Half an Hour: Part 13 --- Containerizing Our Application</p>
</div>
We have an app that works locally. Now it’s time to put it into a container and
yeet it out to a cluster. And that’s what we’ll do.</p>
Lecture</h2>

  </iframe>
</div>
Zero to Prod in Half an Hour: Part 13 --- Containerizing Our Application</p>

Playlist</h2>


Part 1: An Overview of FizzBuzz Pro</a></p>
</li>

Part 2: Generating Static HTML</a></p>
</li>

Part 3: Mutating the Generated HTML Files</a></p>
</li>

Part 4: App Authentication Overview</a></p>
</li>

Part 5: Implementing an OIDC Authenticator</a></p>
</li>

Part 6: Serving Web Pages</a></p>
</li>

Part 7: A Mild Introduction to Middlewares</a></p>
</li>

Part 8: Authenticate All the Things</a></p>
</li>

Part 9: Thinking in Middlewares</a></p>
</li>

Part 10: Authentication and Subscription Middlewares</a></p>
</li>

Part 11: Implementing Authentication Handlers</a></p>
</li>

Part 12: The Final Touches</a></p>
</li>

▶ Part 13: Containerizing Our Application</strong></p>
</li>

Part 14: Onwards to Kubernetes</a></p>
</li>

Creating ECR Repositories</a></p>
</li>

Deploying a Microservice to Kubernetes</a></p>
</li>

Fizz that Buzz</a></p>
</li>

FizzBuzz Pro High-Level Design</a></p>
</li>

FizzBuzz Pro Repositories</a></p>
</li>
</ul>
Tools and Technologies Mentioned</h2>
Here are the tools and technologies that were mentioned in the video, along with
related articles and other helpful links.</p>

Kubernetes</a></li>
Dockerfile Reference</a></li>
Use Multi Stage Builds</a></li>
Container Security</a></li>
Amozon ECR</a></li>
Amazon EKS</a></li>
</ul>
Read The Source</h2>

Download the source code (114kb zip
archive</em>)</a></li>
</ul>

Until the next lecture… May the source be with you 🦄.</p>


A Glossary of Mostly Developer-Related Things
2021-11-27T00:00:00+00:00

    </p>
    
The tech industry loves its TLAs.</p>
</div>
We love our terms and acronyms, don’t we? They help us communicate complex
notions with just a few characters; however, they can also be an obstacle when
you are learning new stuff. This page covers a list of mostly developer-related
terms and acronyms with links to further explanations about them.</p>

A/B Testing</a></li>
API</a></li>
Adaptive Design</a></li>
Agile Software Development</a></li>
Algorithm</a></li>
Automation</a></li>
Backlog</a></li>
bash</a></li>
BDD (Behavior-Driven
Development</em>)</a></li>
Big Data</a></li>
Big Query</a></li>
Browser</a></li>
Bug</a></li>
Bundling</a></li>
Burn Rate</a></li>
C#</a></li>
C++</a></li>
CMS (Content Management
System</em>)</a></li>
CNCF (Cloud Native Computing Foundation</em>)</a></li>
CPU (Central Processing
Unit</em>)</a></li>
CRM (Customer Relationship
Management</em>)</a></li>
CSS (Cascading Style
Sheet</em>)</a></li>
CTA (Call to
Action</em>)</a></li>
C</a></li>
Cache</a></li>
Churn Rate</a></li>
Code Editor</a></li>
CommonJS</a></li>
Container</a></li>
CI (Continuous
Integration</em>)</a></li>
Cookie</a></li>
Crawl</a></li>
DNS (Domain Name System</em>)</a></li>
DNS Record Types</a></li>
DPI (Dots Per Inch</em>)</a></li>
Data Structure</a></li>
Debugging</a></li>
Deployment</a></li>
Design</a></li>
DevOps</a></li>
Docker</a></li>
Domain</a></li>
ECMAScript</a></li>
Erlang</a></li>
FMP (First Meaningful Paint</em>)</a></li>
FP (Functional
Programming</em>)</a></li>
FTP (File Transfer
Protocol</em>)</a></li>
FaaS</a></li>
Favicon</a></li>
Framework</a></li>
Front End and Back End</a></li>
Full-Stack</a></li>
GUI (Graphical User
Interface</em>)</a></li>
GitHub</a></li>
Git</a></li>
Go</a></li>
GraphQL</a></li>
Haskell</a></li>
HTML (Hypertext Markup Language</em>)</a></li>
HTTP Response Status Codes</a></li>
HTTP (Hypertext Transfer
Protocol</em>)</a></li>
humans.txt</a></li>
Hybrid App</a></li>
Hypervisor</a></li>
IaaS (Infrastructure as a
Service</em>)</a></li>
Inbound Marketing</a></li>
Information Architecture</a></li>
Integration Testing</a></li>
JAM Stack</a></li>
JavaScript</a></li>
Java</a></li>
Kaizen</a></li>
Kanban</a></li>
Kubernetes</a></li>
LAMP Stack</a></li>
Library</a></li>
Lisp</a></li>
Local Storage</a></li>
MEAN Stack</a></li>
MERN Stack</a></li>
Mocking</a></li>
MQTT (Message Queue Telemetry Transport</em>)</a></li>
MTTR (Mean Time to
Repair</em>)</a></li>
MVP (Minimum Viable
Product</em>)</a></li>
Machine Learning</a></li>
Minification</a></li>
Mobile App</a></li>
Mockup</a></li>
Module</a></li>
Navigation</a></li>
NIH (Not Invented Here</em>)</a></li>
NoSQL</a></li>
Node.js</a></li>
Orchestration</a></li>
OOP (Object-Oriented
Programming</em>)</a></li>
OOTB (Out of the
Box</em>)</a></li>
OSI Model</a></li>
OWASP (Open Web Application Security Project</em>)</a></li>
Operating System</a></li>
PaaS _Platform as a
Service</em>)</a></li>
Plugin</a></li>
Pod</a></li>
Production</a></li>
Protocol Buffers</a></li>
Prototype</a></li>
Python</a></li>
RAM (Random-Access
Memory</em>)</a>)</li>
REST (Representational State
Transfer</em>)</a></li>
Redirect</a></li>
Registrar</a></li>
Resolution</a></li>
Responsive Design</a></li>
Roadmap</a></li>
robots.txt</a></li>
Ruby</a></li>
Rust</a></li>
SMTP (Simple Mail Transfer
Protocol</em>)</a></li>
SQL (Structured Query Language</em>)</a></li>
SSD (Solid-State Drive</em>)</a></li>
SSH (Secure Shell</em>)</a></li>
SaaS (Software as a
Service</em>)</a></li>
Scheme</a></li>
Scrape</a></li>
Scrum</a></li>
Server</a></li>
Separation of Concerns</a></li>
Spying</a></li>
Serverless</a></li>
Session Storage</a></li>
Sitemap</a></li>
Smalltalk</a></li>
Software Stack</a></li>
Source Control</a></li>
SOLID</a></li>
Sprint</a></li>
TDD (Test-Driven
Development</em>)</a></li>
TLS</a></li>
TTFB (Time to First
Byte</em>)</a></li>
Tags</a></li>
Template</a></li>
Test Stub</a></li>
Text Editor</a></li>
UAT (User Acceptance
Testing</em>)</a></li>
UI Design</a></li>
UI (User Interface</em>)</a></li>
UX Design</a></li>
UX (User Experience</em>)</a></li>
Unit Testing</a></li>
Usability Testing</a></li>
User Agent</a></li>
User Research</a></li>
WYSIWYG (What You See Is What You
Get</em>)</a></li>
Waterfall</a></li>
Web App</a></li>
Widget</a></li>
Wireframe</a></li>
YAGNI</a></li>
zsh</a></li>
</ul>
Until next time… May the source be with you 🦄.</p>

Section Contents</h2>


Be the Next Version of Yourself</a></p>
</li>

Who Else is Ready to Hack?</a></p>
</li>

Grab Your Chisel and Start Pounding</a></p>
</li>

Unlock Your Brain’s Power: Learn Fast, Remember More</a></p>
</li>

Master Your Mind: Unleash the Power of Learning</a></p>
</li>

Resources Every Developer Must Read: No Exceptions</a></p>
</li>

Knowing JavaScript Is Not Good Enough</a></p>
</li>

Learn JavaScript the Unconventional Way</a></p>
</li>

Want to Learn JavaScript? Learn Haskell First</a></p>
</li>

▶ A Glossary of Mostly Developer-Related Things</strong></p>
</li>

Git Comfortable</a></p>
</li>

Master Your Vim-Fu</a></p>
</li>

One Does Not Simply Terminal 👌</a></p>
</li>

Paint Me Like One of Your French Design Patterns</a></p>
</li>

Tame Your Regular Expressions</a></p>
</li>

Security Is Not Optional</a></p>
</li>

You Need Testing</a></p>
</li>

A Startup Founder’s Bedtime Reading List</a></p>
</li>

Orange Is the New Purple</a></p>
</li>

Ramp Up in User Experience Design</a></p>
</li>

Get Better at Typography</a></p>
</li>

The Bottleneck Moved. The Work Did Not.</a></p>
</li>
</ul>


mTLS With SPIRE: Part 1: Introduction
2021-10-19T00:00:00+00:00

    </p>
    
mTLS With SPIRE: Part 1: Introduction</p>
</div>
This video will introduce the cluster architecture and talk about what we are
planning to achieve by the end of the video series.</p>

  </iframe>
</div>
mTLS With SPIRE: Part 1: Introduction</p>

Playlist</h2>


▶ mTLS With SPIRE: Part 1: Introduction</strong></p>
</li>

mTLS With SPIRE: Part 2: Creating the Server App</a></p>
</li>

mTLS With SPIRE: Part 3: Creating the Client App</a></p>
</li>

mTLS With SPIRE: Part 4: Containerizing the Server App</a></p>
</li>

mTLS With SPIRE: Part 5: Containerizing the Client App</a></p>
</li>

mTLS With SPIRE: Part 6: Rolling Out SPIRE to the Cluster</a></p>
</li>

mTLS With SPIRE: Part 7: Registering Nodes and Workloads to SPIRE</a></p>
</li>

mTLS With SPIRE: Part 8: Configuring the Server to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 9: Configuring the Client to Use SPIRE mTLS</a></p>
</li>

mTLS With SPIRE: Part 10: Establishing Cross-Cluster mTLS</a></p>
</li>
</ul>
Tools and Technologies Mentioned</h2>
Here are the tools and technologies that were mentioned in the video, along with
related articles and other helpful links.</p>

Setting Up SPIRE</strong> on EKS in Less
Than Ten Minutes</a> (read this first</em>)</li>
Public Key Infrastructure (PKI</em></strong>)</a></li>
Transport Layer Security (TLS</em></strong>)</a></li>
Mutual Transport Layer Security (mTLS</em></strong>)</a></li>
X.509</strong></a></li>
Kubernetes</a></li>
Containers</a></li>
Pods</a></li>
gRPC</strong></a></li>
SPIFFE</strong></a></li>
SPIRE</strong></a></li>
SPIRE</strong> Federation</a></li>
</ul>
Read the Source</h2>

Access the source code and other related assets from Zero to Hero</strong> GitHub</a>.</li>
</ul>


Pivoting Your Career?
2021-10-02T00:00:00+00:00

    </p>
    
Pivoting is a big decision. Make sure you are ready for it.</p>
</div>
Welcome to the fifteenth issue of Zero to Hero</strong> Highlights.</p>
I’m still deep down into Cloud-Native Security</strong>. The good news is, I’ve
learned “a lot</strong>,” and lots of quality stuff will likely come up your way.</p>
On the topic of “Cloud Native,” I asked the community what Cloud-Native
Security</strong> meant for them.</p>
I did this on Twitter</strong> and other mediums, like IRC</strong>, Slack</strong>, and
Discord</strong>. Then I came up with a 20-page “mini” bedtime reading material,
a Cloud-Native Security DevRel’s survival guide 🥑.</p>
Cloud-Native Security Developer Relations Engineer’s Survival Guide</h2>


    </p>
    
Don't Panic</p>
</div>
I’ve even outlined the blueprint of a book. Not sure if I’ll create a book; or
come off with a series of articles or both. We’ll see 😀.</p>
“Cloud-Native Security Developer Relations Engineer”? Wow, fancy title. But,
what exactly is it?</p>
Here’s how I defined it in the document.</p>

A Cloud-Native Security Developer Relations Engineer</strong> collaborates,
partners, grows, contributes, and hacks</strong> with the Cloud-Native</strong> security
community. They explore new venues find where the developers are, listen to
them and engage with them, mentor and support them, and lift them.</p>
While doing these, they will also be the bridge between the developer
community and the larger Cloud-Native Security</strong> ecosystem. They will share
ideas, solutions, and recommendations, gather feedback, and spread the word to
the observable universe.</p>
</blockquote>
Right now, the document has some Company-specific information, so I cannot quite
publicly release it. Still, I am planning to pivot off a more general document
for the larger community to benefit.</p>
SPIFFE Anyone?</h2>
I also looked into Trust</strong> and Identity Federation</strong> in the cloud.</p>


    </p>
    
SPIRE Tutorial Audio Recording</p>
</div>
I have 18 minutes</strong> of screencast where I deploy a SPIRE</strong></a> server on
an AWS EKS</strong> cluster and then fetch x.509</strong> SVID’s from a workload. If it does
not mean much to you, I promise it’ll make sense after watching the video.</p>
The content is almost ready. It just has some post-production and annotation
work to do before it’ll be ready for your viewing pleasure.</p>
Along with the video, there will be an accompanying article that has been tech
reviewed by not one but two SPIRE</strong></a> core contributors:
Daniel Feldman</strong></a> and Evan Gilman</strong></a>.</p>
So it’ll be awesome</strong>. Wait for it.</p>
Random Thought of the Week</h2>
Are you making a big career decision?</p>
Changing job roles is hard no matter what the circumstances. So before pressing
the big red button, ask yourself the following questions. Once you answer them
all, you’ll have gained clarity and narrowed down your options.</p>
How do you feel about the opportunity</strong>? How do you envision your future when
you do the switch? Think about the kind of work you do right now. Now, think
about the work that you are planning to do. Take a pen and paper and write down
your ideas and feelings.</p>
Does this opportunity align with what matters to you most</strong>? Knowing and
understanding your values will help you make choices that align with what you
care about most.</p>
How does this change will affect others</strong>? Consider how your decision will
impact your family, friends, loved ones, the people you most care about. Then,
before jumping hoops, ask them for their comments, suggestions, insights, and
thoughts.</p>
What’s behind that screensaver</strong>? You want to make the right choice for the
right reason. Be objective. The grass will always look greener from the outside.
Though, are you considering facts and data, or are you considering your hopes
and assumptions? If you make your decision solely based on your gut</em> feeling,
be aware that you are taking the risk of disappointment in the long run. Gather
as much evidence as you can.</p>
Once you answer these questions, and maybe sleep on</strong> the idea a little,
you’ll better understand how to proceed.</p>
Look What I’ve Found</h2>
Here are the things that grabbed my attention this week.</p>
I typically don’t share these anywhere else.</p>
Exclusively hand-picked for you 👌. Enjoy.</p>

skruv</strong> is no-dependency, no-build, small JS framework</a>.</li>
Opossum</strong> is a Node.js circuit breaker that executes asynchronous
functions and monitors their execution status</a>.</li>
globby</strong> is a user-friendly glob matcher</a>.</li>
</ul>
Thanks a Lot ❤️</h2>
That’s all for this week. Next week, I’ll gather more unique content and
resources.</p>
So, until next time… May the source be with you 🦄.</p>

Issues</h2>


Issue 1: Hello World, Hello Stars, Hello Universe</a></p>
</li>

Issue 2: The Only Thing That doesn’t Change is Change Itself</a></p>
</li>

Issue 3: Know Thyself</a></p>
</li>

Issue 4: Have You Fizzed that Buzz?</a></p>
</li>

Issue 5: Be Kind</a></p>
</li>

Issue 6: Earn the Promotion You Deserve</a></p>
</li>

Issue 7: Who Else Journals Daily?</a></p>
</li>

Issue 8: Who Are You?</a></p>
</li>

Issue 9: How to Make Yourself Heard</a></p>
</li>

Issue 10: Tough Conversations</a></p>
</li>

Issue 11: Assemble Your Personal Board of Advisor</a></p>
</li>

Issue 12: What’s Your Plan</a></p>
</li>

Issue 13: Nine-to-Five? I Don’t Think So</a></p>
</li>

Issue 14: Respect and Understanding</a></p>
</li>

▶ Issue 15: Pivoting Your Career?</strong></p>
</li>

Issue 16: Ghosted?</a></p>
</li>

Issue 17: ‘Following Your Passion’ Is Hardly Enough</a></p>
</li>

Issue 18: Keep Cam and Carry On</a></p>
</li>

Issue 19: Attention, Intention, Compassion</a></p>
</li>

Issue 20: Words Matter</a></p>
</li>

Issue 21: Change Is the Only Constant</a></p>
</li>

Issue 22: Overcome the Awkward Feeling of Networking</a></p>
</li>

Issue 23: Unleash Your Curiosity: Unlock Your Potential as a Leader</a></p>
</li>

Issue 24: Interview Done. Radio Silence 🎃 What Now?</a></p>
</li>

Issue 25: Unlock Your True Potential: Make Your Hard Work Visible</a></p>
</li>

Issue 26: Winning at Work: Thriving With Difficult Colleagues</a></p>
</li>

Issue 27: Promotions Don’t Happen Overnight</a></p>
</li>
</ul>


The Journey of a Microservice: From Source Code to a Full-Blown Kubernetes Deployment
2021-08-09T00:00:00+00:00

    </p>
    
The Journey of a Microservice: From Source Code to a Full-Blown Kubernetes Deployment</p>
</div>
Introduction</h2>
In this lecture, we’ll containerize and deploy a **REST
**ful</a> Go microservice
to a Kubernetes</strong></a> cluster. We’ll also learn about
some important building blocks of our cluster such
as Deployment</code></a>
s, Service</code></a>
s, ConfigMap</code></a>
s, Secret</code></a>
s, Ingress</code></a>
es, and the like.</p>
Lecture</h2>

  </iframe>
</div>
Deploying a Microservice to Kubernetes</p>
Below, you’ll find the source code</strong> of the projects that we used in this
video, links, resources, and other reference material for you learn and practice
even further.</p>
Read the Source</h2>
Below, you’ll find the zip archives</strong> of the projects and other related
artifacts that we’ve covered in this article.</p>

fizz-crypto</code> (53KB</strong> zip archive)</a></li>
fizz-infra</code> (29KB</strong> zip archive)</a></li>
</ul>
The Contents of the .netrc File</h2>
machine github.com</span></span>
login your_github_username_comes_here</span></span>
password ghp_your_github_api_key_comes_here</span></span>
machine api.github.com</span></span>
login your_github_username_comes_here</span></span>
password ghp_your_github_api_key_comes_here</span></span></code></pre>The Environment Variables</h2>
Here are the environment variables of interest that our builder script uses:</p>
ECR_REPO</span>=</span>112233445566.dkr.ecr.us-west-2.amazonaws.com</span></span>
ECR_IMAGE_FIZZ_CRYPTO</span>=</span>fizz-crypto</span></span>
ECR_TAG_FIZZ_CRYPTO</span>=</span>0.0.15</span></span></code></pre>ECR Login Script</h2>
Here’s the login script I used in the video:</p>
aws</span> ecr get-login-password</span> --region</span> us-west-2</span> |</span> \</span></span>
docker</span> login</span> --username</span> AWS</span> --password-stdin \</span></span>
1122334455667788.dkr.ecr.us-west-2.amazonaws.com</span></span></code></pre>

Note</strong></p>
To use the above script, you need
to install and configure AWS CLI</a>
first.</p>
</blockquote>
Resources and Additional Reading</h2>
Services We Used in the Video</h3>

Amazon Elastic Kubernetes Service</a></li>
Papertrail: Frustration-free Log Management</a></li>
</ul>
Kubernetes</h3>

Kuberetes</a></li>
Kubernetes Special Interest Groups (_SIG_s)</a></li>
Kubernetes: Performing a Rolling Update</a></li>
Configuring Access to Multiple Clusters</a></li>
Configuring Liveness, Readiness, and Startup Probes</a></li>
</ul>
Kubernetes API Objects That We Saw in the Video</h3>

Deployment</code></a></li>
ReplicaSet</code></a></li>
Service</code></a></li>
ConfigMap</code></a></li>
Secret</code></a></li>
Ingress</code></a></li>
Job</code></a></li>
</ul>
Containers</h3>

Containers</a></li>
Docker Engine</strong> Overview</a></li>
containerd</strong> Overview</a></li>
What is cri-o</strong></a></li>
Managing Resources for Containers</a></li>
CRI</strong>: Container Runtime Interface</a></li>
</ul>
Container Images We Used</h3>

golang</code> Official Docker Image</a></li>
netshoot</code>: a Docker + Kubernetes network trouble-shooting swiss-army container</a></li>
</ul>
Building Images</h3>

Dockerfile</code> reference</a></li>
Using multi-stage builds</a></li>
</ul>
Best Practices</h3>

What is a REST API</a></li>
Semantic Versioning</a></li>
</ul>
GitHub Access Tokens</h3>

.netrc</code> File</a></li>
Creating GitHub</strong> Personal Access Tokens</a></li>
</ul>
Linux</h3>

.zprofile, .zshrc, .zenv, OMG! What Do I Put Where?! (a Zero to Hero</strong> article</em>)</a></li>
curl</code></a></li>
telnet</code></a></li>
</ul>
Playlist</h2>


Part 1: An Overview of FizzBuzz Pro</a></p>
</li>

Part 2: Generating Static HTML</a></p>
</li>

Part 3: Mutating the Generated HTML Files</a></p>
</li>

Part 4: App Authentication Overview</a></p>
</li>

Part 5: Implementing an OIDC Authenticator</a></p>
</li>

Part 6: Serving Web Pages</a></p>
</li>

Part 7: A Mild Introduction to Middlewares</a></p>
</li>

Part 8: Authenticate All the Things</a></p>
</li>

Part 9: Thinking in Middlewares</a></p>
</li>

Part 10: Authentication and Subscription Middlewares</a></p>
</li>

Part 11: Implementing Authentication Handlers</a></p>
</li>

Part 12: The Final Touches</a></p>
</li>

Part 13: Containerizing Our Application</a></p>
</li>

Part 14: Onwards to Kubernetes</a></p>
</li>

Creating ECR Repositories</a></p>
</li>

▶ Deploying a Microservice to Kubernetes</strong></p>
</li>

Fizz that Buzz</a></p>
</li>

FizzBuzz Pro High-Level Design</a></p>
</li>

FizzBuzz Pro Repositories</a></p>
</li>
</ul>
Conclusion</h2>
That was how you can containerize and deploy a Go</strong>-based microservice to a
Kubernetes</strong> cluster.</p>
We’ll have more Go</strong> programming and Kubernetes</strong> deployments in the
upcoming future.</p>
Until next time… May the source be with you 🦄.</p>


Who Else Journals Daily?
2021-06-26T00:00:00+00:00

    </p>
    
Journaling is self-reflection.</p>
</div>
Welcome to the seventh issue of Zero to Hero</strong> Highlights.</p>
This week, I was busy refactoring a tiered enterprise Java Spring</strong> project.
It consumed more time that I anticipated. Can I say I’m a JavaSpring</strong>
developer now 😀 (instead of “JavaScript”—get it, get it?</em>)—okay, lousy dad
pun. But still, I had to shift my schedule to adapt to tackling with that beast,
which consumed a lot</strong> of my time and energy.</p>
The good part</strong>: I learned a heck lot of Spring Cloud</em></strong></a>
and Spring Security</em></strong></a> internals,
more than I’d like to know, actually. My verdict is: Although Java has moved a
long way since J2EE</em>, and with the Spring Framework</strong></a>**,
**it’s on the right path; yet I still do think it is heavy</strong> and verbose</strong>.</p>

The Spring Framework</strong></a> is still worth learning if</em></strong>
you want to shoot flies using rocket launchers 😜—kidding, or maybe not</strong>.
Anyhoo, try it yourself</a> and tell me how your learning
experience went.</p>
</blockquote>
What’s New on Zero to Hero</strong> 👩‍🍳</h2>
This week, I mainly did infrastructure and plumbing work, such as creating
container images and ensuring that FizzBuzz Pro</strong> microservices are at least
answering to health</em> and liveness</em> endpoints.</p>


    </p>
    
Creating a go Docker image.</p>
</div>

I don’t have a definite schedule. Yet, since I work during the day, I’ll
mostly be streaming at nights (pacific time</em>)—stay tuned.</p>
I stream every couple of days; however, it also depends on my energy levels,
and the programs that I might have with family and friends.</p>
The best way to get notified as soon as I’m online is
to hop on the channel and follow me on Twitch</strong></a>.</p>
</blockquote>
Other than the live streams, there’s not much visible progress, but many cool
things are brewing behind-the-scenes—stay tuned.</p>
Random Thought of the Week</h2>
Do you keep a journal? If not, you should.</p>
Your journal also helps to start your day with a set of probing questions. Here
are the five questions I ask myself every single day</strong> and how those questions
change and shape my life:</p>


    </p>
    
The questions I ask to myself every single day.</p>
</div>
What is it that you really want to be and do?</h3>
This question is about your aspiration</strong> and purpose</strong>. What is it that you
do, and what is it that you really</strong> want to be great at doing. The key is to
be honest</strong> with yourself. The question does not read “what do people want
you to become?</em>”, it asks what is it that YOU</strong> want to be and do.</p>
What are you doing really well that is helping you get there?</h3>
This question helps you spotlight a core strength and your ability to execute
towards your goal.</p>
What are you not doing well that is preventing you from getting there?</h3>
This, again, requires an honest and critical assessment of the things that block
your way.</p>
What will you do differently tomorrow to meet those challenges?</h3>

Don’t practice your forehand while your backhand sucks.</p>
</blockquote>
This question pushes you to focus on the right priorities so that you don’t get
into a situation of “I am making good time, but I am lost.</em>” It also helps move
you out of your comfort zone.</p>
How can I help myself / where do I need the most help?</h3>
The answers to the first four questions match against areas where you (as your
own mentor</em>) can have particular strengths. In contrast, the second question
helps you to open up to your network to ask for help</strong>.</p>
Keep on Journaling</h2>
I journal a lot, initially with pen and paper and later on digitally. I believe
it’s a transformative</strong> experience that everyone needs to give it an honest
try at least.</p>

Your journal is a regular private, personal, honest</strong>, and truthful</strong>
self-diagnosis that can take at most two minutes</strong> of your time.

If you don’t have two minutes a day to spare, well, then you do need to sort
out your priorities.</p>
</blockquote>
Besides, journaling is not a big hurdle: You are not writing a novel or an
essay—unless you want to. You can use anything to journal: Pen and paper works
just fine; you can use a dedicated app, or you can fire your favorite text
editor. It doesn’t matter.</p>
Keeping a journal clears your mind off of random thoughts, helps you keep on
track and achieve your goals and clarifies your intentions.</p>
Look What I’ve Found</h2>
Here are the things that grabbed my attention this week.</p>
I typically don’t share these anywhere else.</p>
Exclusively hand-picked for you 👌. Enjoy.</p>

Run any code on any client with WebAssembly</strong> and Wasmer</strong></a>.</li>
IEEE754</strong> anyone</a>?</li>
Fed up from the React/Vue/Angular madness?—Alpine</strong> is a rugged, minimal
framework for composing JavaScript</strong> behavior in your markup</a>.</li>
</ul>

Issues</h2>


Issue 1: Hello World, Hello Stars, Hello Universe</a></p>
</li>

Issue 2: The Only Thing That doesn’t Change is Change Itself</a></p>
</li>

Issue 3: Know Thyself</a></p>
</li>

Issue 4: Have You Fizzed that Buzz?</a></p>
</li>

Issue 5: Be Kind</a></p>
</li>

Issue 6: Earn the Promotion You Deserve</a></p>
</li>

▶ Issue 7: Who Else Journals Daily?</strong></p>
</li>

Issue 8: Who Are You?</a></p>
</li>

Issue 9: How to Make Yourself Heard</a></p>
</li>

Issue 10: Tough Conversations</a></p>
</li>

Issue 11: Assemble Your Personal Board of Advisor</a></p>
</li>

Issue 12: What’s Your Plan</a></p>
</li>

Issue 13: Nine-to-Five? I Don’t Think So</a></p>
</li>

Issue 14: Respect and Understanding</a></p>
</li>

Issue 15: Pivoting Your Career?</a></p>
</li>

Issue 16: Ghosted?</a></p>
</li>

Issue 17: ‘Following Your Passion’ Is Hardly Enough</a></p>
</li>

Issue 18: Keep Cam and Carry On</a></p>
</li>

Issue 19: Attention, Intention, Compassion</a></p>
</li>

Issue 20: Words Matter</a></p>
</li>

Issue 21: Change Is the Only Constant</a></p>
</li>

Issue 22: Overcome the Awkward Feeling of Networking</a></p>
</li>

Issue 23: Unleash Your Curiosity: Unlock Your Potential as a Leader</a></p>
</li>

Issue 24: Interview Done. Radio Silence 🎃 What Now?</a></p>
</li>

Issue 25: Unlock Your True Potential: Make Your Hard Work Visible</a></p>
</li>

Issue 26: Winning at Work: Thriving With Difficult Colleagues</a></p>
</li>

Issue 27: Promotions Don’t Happen Overnight</a></p>
</li>
</ul>


Creating ECR Repositories
2021-06-18T00:00:00+00:00

    </p>
    
These are 'elastic' containers.</p>
</div>
This quick video will create an AWS ECR</strong></a> repo
and set up our development environment to interact with it.</p>

  </iframe>
</div>
Creating ECR Repositories</p>
Resources and Additional Reading</h2>

Amazon Elastic Container Registry</a></li>
Installing the AWS CLI</a></li>
What is a Container</a></li>
</ul>
Playlist</h2>


Part 1: An Overview of FizzBuzz Pro</a></p>
</li>

Part 2: Generating Static HTML</a></p>
</li>

Part 3: Mutating the Generated HTML Files</a></p>
</li>

Part 4: App Authentication Overview</a></p>
</li>

Part 5: Implementing an OIDC Authenticator</a></p>
</li>

Part 6: Serving Web Pages</a></p>
</li>

Part 7: A Mild Introduction to Middlewares</a></p>
</li>

Part 8: Authenticate All the Things</a></p>
</li>

Part 9: Thinking in Middlewares</a></p>
</li>

Part 10: Authentication and Subscription Middlewares</a></p>
</li>

Part 11: Implementing Authentication Handlers</a></p>
</li>

Part 12: The Final Touches</a></p>
</li>

Part 13: Containerizing Our Application</a></p>
</li>

Part 14: Onwards to Kubernetes</a></p>
</li>

▶ Creating ECR Repositories</strong></p>
</li>

Deploying a Microservice to Kubernetes</a></p>
</li>

Fizz that Buzz</a></p>
</li>

FizzBuzz Pro High-Level Design</a></p>
</li>

FizzBuzz Pro Repositories</a></p>
</li>
</ul>
Next Up</h2>
Next on my video production queue are:</p>

Going through the sequence diagrams of FizzBuzz Pro</strong> authentication,
subscription, and signup flow.</li>
How to harden our IAM account security</strong>.</li>
And a quickie about Ghost theme development</strong>.</li>
</ul>
Once those videos are done, we’ll start working on actually implementing the *
FizzBuzz Pro</em>* infrastructure, one microservice at a time; it’ll be fun.</p>
Until the next video… May the source be with you 🦄.</p>

Zero to Hero - cloud-native

Understanding Docker's 6MB Memory Limit: A Deep Dive

Configuration Options: What Can You Do?</h2> While this limit is hardcoded into Docker’s engine, you’re not entirely without options. Here are several approaches to dealing with this limitation:</p>

1. Adjust Your Resource Allocation</h3> The most straightforward solution is to ensure your containers have adequate memory allocation. If you’re hitting this limit, it’s worth questioning whether running with such minimal memory is truly optimal for your application.</p>

Additional Resources</h3> Docker Documentation on Resource Constraints</li> Kubernetes Memory Management Documentation</li> Container Runtime Comparisons</li> Memory Optimization Strategies for Containers</li> </ul> Happy containerizing!</p>

Building a Secure Webhook Server with Go and Docker: A Step-by-Step Guide

Project Overview</h2> Our webhook server is designed to handle secure GET requests with query parameters, process JSON data, and implement basic authentication. The server listens on port 8443 and includes detailed request logging for debugging purposes.</p>

Next Steps</h2> Consider enhancing the application with:</p> TLS support</li> Rate limiting</li> Comprehensive logging</li> Metrics collection</li> Health check endpoints</li> </ul> Happy coding!</p>

Implementing Flexible Authentication Strategies in Go: A Real-World Example with External Secrets Operator

Implementing the Strategies</h2>

Building a Secure Secrets Management Server in Go

Implementation Details</h2>

Cross-Compiling Go Applications on M3 Macs: A Practical Guide

Keep Your Secrets... Secret: Introducing VMware Secrets Manager

Long Live Aegis!

Unlock Your True Potential: Make Your Hard Work Visible

Thanks a Lot ❤️</h2> That’s all for this week. Next week, I’ll gather more unique content and resources.</p> So, until next time… May the source be with you 🦄.</p>

Zero to Prod in Half an Hour: Part 1 --- An Overview of FizzBuzz Pro

Lecture</h2> </iframe> </div> Zero to Prod in Half an Hour: Part 1 --- An Overview of FizzBuzz Pro</p>

Playlist</h2> ▶ Part 1: An Overview of FizzBuzz Pro</strong></p> </li>

mTLS With SPIRE: Part 5: Containerizing the Client App

mTLS With SPIRE: Part 4: Containerizing the Server Appp

Zero to Prod in Half an Hour: Part 13 --- Containerizing Our Application

Lecture</h2> </iframe> </div> Zero to Prod in Half an Hour: Part 13 --- Containerizing Our Application</p>

A Glossary of Mostly Developer-Related Things

mTLS With SPIRE: Part 1: Introduction

Playlist</h2> ▶ mTLS With SPIRE: Part 1: Introduction</strong></p> </li>

Pivoting Your Career?

Thanks a Lot ❤️</h2> That’s all for this week. Next week, I’ll gather more unique content and resources.</p> So, until next time… May the source be with you 🦄.</p>

The Journey of a Microservice: From Source Code to a Full-Blown Kubernetes Deployment

Lecture</h2> </iframe> </div> Deploying a Microservice to Kubernetes</p> Below, you’ll find the source code</strong> of the projects that we used in this video, links, resources, and other reference material for you learn and practice even further.</p>

The Environment Variables</h2> Here are the environment variables of interest that our builder script uses:</p>

ECR Login Script</h2> Here’s the login script I used in the video:</p>

Who Else Journals Daily?

What are you not doing well that is preventing you from getting there?</h3> This, again, requires an honest and critical assessment of the things that block your way.</p>

Creating ECR Repositories

Configuration Options: What Can You Do?</h2>
While this limit is hardcoded into Docker’s engine, you’re not entirely without options. Here are several approaches to dealing with this limitation:</p>

1. Adjust Your Resource Allocation</h3>
The most straightforward solution is to ensure your containers have adequate memory allocation. If you’re hitting this limit, it’s worth questioning whether running with such minimal memory is truly optimal for your application.</p>

Additional Resources</h3>

Docker Documentation on Resource Constraints</li>
Kubernetes Memory Management Documentation</li>
Container Runtime Comparisons</li>
Memory Optimization Strategies for Containers</li> </ul>
Happy containerizing!</p>

Project Overview</h2>
Our webhook server is designed to handle secure GET requests with query parameters, process JSON data, and implement basic authentication. The server listens on port 8443 and includes detailed request logging for debugging purposes.</p>

Next Steps</h2>
Consider enhancing the application with:</p>

TLS support</li>
Rate limiting</li>
Comprehensive logging</li>
Metrics collection</li>
Health check endpoints</li> </ul>
Happy coding!</p>

Thanks a Lot ❤️</h2>
That’s all for this week. Next week, I’ll gather more unique content and resources.</p>
So, until next time… May the source be with you 🦄.</p>

Thanks a Lot ❤️</h2>
That’s all for this week. Next week, I’ll gather more unique content and resources.</p>
So, until next time… May the source be with you 🦄.</p>

What are you not doing well that is preventing you from getting there?</h3>
This, again, requires an honest and critical assessment of the things that block your way.</p>