Forem: Dave Sudia

How to Integrate Docker & JetBrains into Telepresence

Dave Sudia — Tue, 07 Nov 2023 16:56:47 +0000

You are a developer who enjoys experimenting while striving for optimal solutions. In the past, this was straightforward because your development work occurred on your own workstation. However, you now find yourself in a situation where your applications run within a container managed by a Kubernetes cluster. To implement any changes, you must first build a container and then deploy it to the cluster to have them tested.

When the container malfunctions, debugging becomes challenging; you are forced to rely on log outputs or various metrics to make educated guesses about the underlying issues.

The missing piece

Telepresence enables the interception of a container within the cluster, redirecting all its traffic to a container running on your local workstation. The local container will have access to identical environment variables, share the same mounted directories, and connect to a network that acts as a proxy for the cluster container's network.

Telepresence virtually positions the local container within the cluster, empowering you to debug, modify, rebuild, and restart the container as often as needed, all without the need to commit or deploy any of these changes.

Debugging the container

Remote run/debug configuration

Debugging code running in containers is fairly trivial. Typically, it involves a debugger frontend, often integrated into an IDE, which connects to a debugger backend in the container via a TCP port. The backend may be an integral part of a runtime environment like the Java Virtual Machine (JVM), or it could exist as a distinct binary application, exerting precise control over another compiled binary.

IDEs like JetBrains and VSCode can be configured to perform debugging via a TCP port.

Example using IntelliJ IDEA

Prerequisites:

A running docker environment
IntelliJ IDEA
Telepresence 2.16.1 or later
A Kubernetes cluster where the container can be deployed and intercepted

Prepare a container with a development and a production target

This example builds on the Docker Getting started with Java guide. Reading it is recommended.

We'll employ a Multi-stage Dockerfile as outlined in the guide. The development container runs the code using ./mvnw spring-boot:run with specific JVM options to enable debugging. On the other hand, the production container utilizes the java command to execute precompiled JAR files generated by ./mvnw package.

This Dockerfile is placed at the root of the project.

FROM eclipse-temurin:17-jdk-jammy as base
WORKDIR /app
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:resolve dependency:resolve-plugins
COPY src ./src

FROM base as development
CMD ["./mvnw", "spring-boot:run", "-Dspring-boot.run.jvmArguments='-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:40000'"]

FROM base as build
RUN ./mvnw package

FROM eclipse-temurin:17-jre-jammy as production
EXPOSE 8080
COPY --from=build /app/target/spring-petclinic-*.jar /spring-petclinic.jar
CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/spring-petclinic.jar"]

We also need a .dockerignore file to prevent intermediate files from the build being copied into the container. It contains one single line:

target

Build and push the image

Use docker to build and tag the image. In this example I use the docker registry “thhal”. You’ll need to swap that to a registry that you can push images to.

$ docker build . --tag petclinic --tag thhal/petclinic:1.0.0
$ docker push thhal/petclinic:1.0.0

Deploy the image in the cluster

We need a service and a deployment in the cluster, so we add the following petclinic.yaml to define those.

---
apiVersion: v1
kind: Service
metadata:
  name: petclinic
spec:
  type: ClusterIP
  selector:
    service: petclinic
  ports:
    - name: proxied
      port: 80
      targetPort: http
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: petclinic
  labels:
    service: petclinic
spec:
  replicas: 1
  selector:
    matchLabels:
      service: petclinic
  template:
    metadata:
      labels:
        service: petclinic
    spec:
      containers:
        - name: petclinic
          image: thhal/petclinic:1.0.0
          ports:
            - containerPort: 8080
              name: http

And then we apply that yaml using the command:

$ kubectl apply -f petclinic.yaml

Point your browser to the service. It should show the home page of the Petclinic app. See the tip below If your cluster doesn’t have an ingress controller configured that will allow you to access the service from a browser.

Prepare a Run/Debug Configuration in the IDE

In the IntelliJ IDE, you can create a “Remote Run/Debug Configuration”. Its only purpose is to connect to a debugger that runs on a given port. That’s exactly what we want.

From the “Run” menu, select “Edit configurations”
Click the plus-sign in the upper left corner.
Select “Remote JVM Debug” in the list that appears.

You’ll end up with a configuration that looks like this.

In this example, I named this configuration “Remote on port 40000”.

Connect Telepresence to the cluster

Use the following command to connect telepresence in docker mode so that the daemon runs in a container. We also use --expose 40000:40000 here to ensure that the port that the JVM will listen to can be reached from the IDE.

$ telepresence connect --docker --expose 40000:40000
Launching Telepresence User Daemon
Connected to context default, namespace default

Running the daemon in a container ensures that the proxied cluster network is isolated from the host network, and that any volume mounts are invisible to the host.

Add your breakpoints

Use the IDE to add some breakpoints to your source code.

Debug the intercept

Now start the intercept in a terminal using --docker-build flag so that it builds the development container, starts it, and ensures that it uses the correct network, environment, and volume mounts. Once the container is up and running, the Java debugger now awaits commands on port 40000.

$ telepresence intercept petclinic --docker-build . \
  –-docker-build-opt target=development -- IMAGE

Start debugging

Start the debugger in your IDE using the “Remote on port 40000” configuration that we created above. Your debug session is now up and running. Try and send some traffic to the cluster that is routed to the intercepted service and watch your breakpoints get hit.

Modify code

Code modification is a four-step process.

Modify the source code.
Stop the Run/Debug configuration
Start the intercept again.
Start the Run/Debug configuration.

Example using Jetbrains Goland IDE

Prerequisites:

A running docker environment
Jetbrains Goland IDE
Telepresence 2.16.1 or later
Source code for the docker container
A Kubernetes cluster where the container is deployed and interceptable

The source code used in this example can be found here.

Prepare a debug version of the container

Go is a compiled language, and debugging requires a debugger called Delve to control the binary. This implies that the container hosting the binary must also include Delve, necessitating a Dockerfile specifically customized for this purpose. The original container (the one running in the cluster) used for this example is built from this Dockerfile

FROM golang:alpine AS builder

WORKDIR /echo-server
COPY go.mod .
COPY go.sum .
# Get dependencies - will also be cached if we won't change mod/sum
RUN go mod download

COPY frontend.go .
COPY main.go .
RUN go build -o echo-server .

FROM alpine
COPY --from=builder /echo-server/echo-server /
CMD ["/echo-server"]

We name the Delve annotated copy Dockerfile.debug

FROM golang:alpine AS builder

# Build Delve
RUN go install github.com/go-delve/delve/cmd/dlv@latest

WORKDIR /echo-server
COPY go.mod .
COPY go.sum .
#Get dependencies - will also be cached if we won't change mod/sum
RUN go mod download

COPY frontend.go .
COPY main.go .
RUN go build -gcflags="all=-N -l" -o echo-server .

EXPOSE 40000
CMD ["/go/bin/dlv", "--listen=:40000", "--headless=true", "--api-version=2", "--accept-multiclient", "exec", "/echo-server/echo-server"]

Notable additions to the debug container are:

Go build disables inlining and optimizations using --gcflags=”all=-N -l”
Delve is installed
The container exposes port 40000 (any free port can be used here).
The CMD is modified so that Delve listens to the exposed port and executes the go binary.
The extra FROM and COPY steps to minimize the container are removed because this container will never be published

Prepare a Run/Debug Configuration in the IDE

In the Goland IDE, you can create a “Go Remote Run/Debug Configuration”. Its only purpose is to connect to a debugger that runs on a given port. That’s exactly what we want.

From the “Run” menu, select “Edit configurations”
Click the plus-sign in the upper left corner.
Select “Go remote” in the list that appears.

You’ll end up with a configuration that looks like this.

In this example, I named this configuration “Remote on port 40000”.

Connect Telepresence to the cluster

Use the following command to connect telepresence in docker mode so that the daemon runs in a container. We also use --expose 40000:40000 here to ensure that the port that Delve will listen to can be reached from the IDE.

$ telepresence connect --docker --expose 40000:40000
Launching Telepresence User Daemon
Connected to context default, namespace default

Running the daemon in a container ensures that the proxied cluster network is isolated from the host network, and that any volume mounts are invisible to the host.

Add your breakpoints

Use the IDE to add some breakpoints to your source code.

Debug the intercept

Now start the intercept in a terminal using --docker-debug flag. This starts the container with relaxed security and ensures that it uses the correct network, environment, and volume mounts. Once the container is up and running, the Delve debugger now awaits commands on port 40000.

$ telepresence intercept echo --docker-debug Dockerfile.debug -- IMAGE

It’s assumed that the name of the cluster deployment that runs our container remotely is “echo”.

Start debugging

Modify code

Code modification is a four-step process.

Modify the source code.
Stop the Run/Debug configuration
Start the intercept again.
Start the Run/Debug configuration.

This example was inspired by the excellent Goland blog-post Debugging a Go application inside a Docker container.

Tips

Just run the container

Just build and run the original container using the following command If you just want to try out source changes without starting a debugger:

$ telepresence intercept echo --docker-build . -- IMAGE

Bash with cluster network access

Start a bash shell with cluster network access so that you can curl your services by name. The trick here is to start a container that uses the same network as the Telepresence daemon. The name of that network is included in the output from the telepresence status command.

$ docker run --network $(telepresence status --output json | jq -r .user_daemon.container_network) \
  --rm -it jonlabelle/network-tools
[network-tools]$ curl echo
Request served by echo-76547fc7f8-hr2sg

GET / HTTP/1.1

Host: echo
Accept: */*
User-Agent: curl/8.3.0

On a windows box, you’ll need to first execute the telepresence status command, copy the entry for the “Container network” and then use that for the --network option in the docker run command.

See jonlabell/network-tools for more information about this very useful container.

Browser access without Ingress

You can utilize Kubernetes port-forwarding to establish a connection between your browser and a service within your cluster. This proves especially useful when you lack a dedicated ingress for the service. For instance, if you have a "petclinic" service running on port 80 (as demonstrated in the Java example) and you wish to access it from your browser, you can achieve this by executing the following command in your terminal, which maps "localhost:8080" to that service::

$ kubectl port-forward svc/petclinic 8080:80

Now point your browser to http://localhost:8080/

Best Kubernetes DevOps Tools: A Comprehensive Guide

Dave Sudia — Mon, 16 Oct 2023 22:37:44 +0000

Kubernetes has become the standard for container orchestration and is integral to modern DevOps workflows. However, realizing Kubernetes' full potential requires adopting the proper DevOps tools tailored for it. These Kubernetes DevOps tools enable building, testing, deploying, monitoring, and managing applications on Kubernetes efficiently.

This comprehensive guide explores the top DevOps tools purpose-built for Kubernetes to streamline workflows. It covers solutions for CI/CD, deployment, monitoring, automation, and more. The guide also highlights Telepresence as an innovative Kubernetes DevOps tool for accelerated development workflows.

With a robust Kubernetes DevOps toolkit, teams can optimize workflows for application development and delivery. The ecosystem of specialized tools addresses processes and collaboration on top of Kubernetes’ core orchestration capabilities. Selecting the right solutions unlocks improved productivity, resilience, and agility.

The Intersection of DevOps and Kubernetes

DevOps emphasizes practices like continuous integration, infrastructure as code, monitoring, and team collaboration. Kubernetes naturally complements these principles.

Its api-driven architecture allows infrastructure changes to be version controlled and replicated identically across environments. Automated deployments become easier by packaging applications as Kubernetes resources.

Runtime logging and monitoring give observability into apps. The portability of Kubernetes clusters enables multiple teams to work together.

This synergy makes Kubernetes a catalyst for DevOps transformation. But the technology is only one piece. Having the proper Kubernetes tooling is key to unlocking the full benefits.

Best Kubernetes DevOps Tools

Here are some of the top Kubernetes DevOps tools to streamline your workflow:

Continuous Integration Tools

Jenkins is an open source automation server that enables continuous integration and delivery pipelines. The Kubernetes plugin allows dynamic provisioning of agents as pods on a Kubernetes cluster. The plugin also allows Jenkins agents to be dynamically provisioned as pods within clusters. This enables scaling up CI capacity on-demand when workloads increase. Agents can build Docker images, execute tests, and deploy artifacts directly within a Kubernetes environment.
GitLab CI - GitLab CI has integrated support for Kubernetes to natively build, test, and deploy applications to Kubernetes clusters through pipelines. GitLab can deploy review apps and production apps to Kubernetes out of the box. Pipelines can launch Kubernetes jobs to run CI steps in pods with required dependencies. GitLab also offers Kubernetes cluster management, auto-scaling, monitoring, and more.
CircleCI - CircleCI provides flexible workflows and orchestration to build, test, and deploy applications securely onto Kubernetes for teams. It enables you to seamlessly integrate pre-configured Kubernetes operations into your CI/CD pipelines using orbs. These orbs serve as reusable packages of configuration, allowing you to manage various Kubernetes-related tasks within your CircleCI workflows efficiently.

Continuous Deployment Tools

Helm is a package manager that helps define, install, and manage complex Kubernetes applications packaged as charts with manifests, configs, and docs. Helm streamlines deploying complex packaged Kubernetes applications. Developers can create configurable Helm charts wrapping all YAML manifests, configs, and services needed to run an app. Ops teams can then deploy those charts easily across different environments and clusters.
Kustomize provides a template-free way to customize Kubernetes YAML configurations using overlays and generators without templates. It is ideal for customizing YAML configs for multiple Kubernetes environments like dev, staging, and prod. Engineering teams can define common resources in a base and then apply overlays with patches, variable substitutions, and images per environment.
Flux CD enables continuous deployment to Kubernetes through GitOps by syncing Git repositories with Kubernetes clusters. Flux CD enables GitOps for Kubernetes through source control integration. It manages Kubernetes manifests as code and syncs git repo changes to clusters. Flux automates checks, deployments, and updates within clusters.
KEDA introduces event-driven scaling to Kubernetes workloads. It integrates with Kubernetes Horizontal Pod Autoscalers and can scale pods based on external metrics from services like databases and message queues (Kafka, RabbitMQ, MongoDB).

Monitoring & Logging

Prometheus is a leading open source monitoring and alerting system explicitly designed for Kubernetes environments with native support for metrics. Prometheus auto-discovers Kubernetes pods, services, and nodes to collect metrics seamlessly. Its Kubernetes service discovery integration scrapes metrics from API objects like deployments, jobs, and ingresses. Prometheus alerts can trigger autoscaling and remediation based on Kubernetes events and statuses.
Grafana provides an intuitive dashboard interface to visualize metrics collected from sources like Prometheus. It offers out-of-the-box dashboards tailored for monitoring Kubernetes clusters, nodes, deployments, and pods. Users can create custom panels and graphs to build dashboards optimized for their Kubernetes workloads and services. Through dynamic metric visualizations, Grafana helps gain visibility into cluster resource usage, application performance, user activity, and more. Its annotation feature can mark deployment events on graphs.
Datadog provides end-to-end observability, including dashboards, alerts, and log management tailored for monitoring Kubernetes clusters and cloud-native apps. It integrates with Kubernetes to collect metrics and logs from containers, pods, nodes, and controllers. It offers out-of-the-box dashboards for Kubernetes monitoring, namespace mapping, cluster troubleshooting, and more. Datadog's Kubernetes autodiscovery enables tracking dynamic changes.

Automation & Configuration

Terraform provides robust support for provisioning and managing Kubernetes infrastructure as code. The Kubernetes provider integrates deeply to manage resources like clusters, nodes, ingress, storage, RBAC controls, and more. Terraform modules help configure secure and production-ready Kubernetes setups across providers.
Pulumi - takes an infrastructure-as-code approach to Kubernetes using real programming languages like JavaScript, Python, and Go instead of declarative configs. Pulumi's Kubernetes support allows the defining of clusters, configmaps, deployments, and infrastructure in code. It integrates seamlessly with Kubernetes CLI and APIs for full control through code. Pulumi provides flexible abstractions and reuse through packages and libraries.
Ansible provides over 500 modules in the Kubernetes collection for automating tasks within clusters. Modules can deploy apps, configure clusters, manage nodes, handle networking, autoscaling, and security. Ansible is agentless, using OpenSSH to connect and leverage the Kubernetes API. Ansible integrates smoothly with Kubernetes tools like Helm, Kubespray, and Terraform. Ansible playbooks and Kubernetes modules enable automated and idempotent management of production Kubernetes infrastructure.
Kubespray automates production-grade deployment of Kubernetes clusters across cloud providers. It integrates natively with tools like Ansible, Terraform, Helm, and Kustomize for full lifecycle management. Kubespray handles cluster provisioning, configuration, upgrading, scaling, and more to simplify Kubernetes cluster operations.

Secret Management Tools

CyberArk Conjur integrates with Kubernetes to provide robust secret management, access controls, and identity management capabilities essential for secure DevOps workflows. It enables teams to manage credentials, keys, certificates securely, and other secrets needed across Kubernetes environments and pipelines. Conjur brings auditing visibility, granular access policies, and RBAC integration to strengthen security across the Kubernetes stack. Its automation and integration with CI/CD pipelines and infrastructure as code tools gives Engineering teams more control over secrets management as they adopt Kubernetes.
HashiCorp Vault manages and secures sensitive secrets like tokens, passwords, keys, and certificates used by Kubernetes clusters, applications, and tools. It centralizes secrets management with encryption, revocation, renewal, and auditing to provide teams visibility and control. Vault integrates with CI/CD and infrastructure as code tools to inject secrets safely into Kubernetes environments. Its dynamic secrets and automatic rotation remove manual burdens for teams. These capabilities make Vault a crucial DevOps tool for securely automating secrets handling as part of Kubernetes workflows.
AWS Secrets Manager integrates deeply with Kubernetes to control access and reduce risks related to important secrets like database credentials and API keys used by applications. It brings fine-grained access controls, least privilege permissions, and audit trails to improve Kubernetes secrets security. Secrets Manager eliminates manual secret handling through automated rotation and versioning. Together, its ability to manage credentials at scale while providing visibility makes Secrets Manager an essential DevOps tool for teams adopting Kubernetes.

Using Telepresence for Kubernetes Development

Telepresence is a developer productivity tool that connects your local development environment to a cluster, allowing you to maintain your favorite local development practices while working as if you were in your integration environment.

You can run telepresence connect and talk to pods in the cluster via your browser or curl as if you were a pod in the cluster. You can also Intercept pods in the cluster and have requests to that pod come to the locally running code on your laptop, bringing the fast feedback of local development to Kubernetes. Some unique benefits of Telepresence include:

Fewer environments to manage: With Telepresence, developers can share a development or staging cluster and receive just their test requests.
Cost savings: When developers don’t need their own dev environments and databases, your cloud bill shrinks with every node you can turn off.
No more tedious build-test-deploy cycles: Developers work faster and use less CI time by making live code changes proxied to remote Kubernetes clusters.

This lightweight, local development experience accelerates iterating on apps interacting with remote Kubernetes services. Teams can catch issues early before deploying to production. Telepresence simplifies developing microservices on Kubernetes, bridging local and remote environments seamlessly.

Key Criteria for Evaluating Kubernetes DevOps Tools

With the plethora of tools available, focus on these factors when choosing solutions:

User-Friendliness: Seek tools with intuitive interfaces and easy adoption. Complexity hinders productivity.
Compatibility: Integration with other tools in the stack is key. Prioritize open standards over walled gardens.
Community Backing: Look for active user communities that drive improvements and provide learning resources.
Pricing: Balance feature set against the total cost of ownership for commercial tools. Avoid vendor lock-in.
Scalability & Performance: Tools must scale alongside usage without degradation. Review benchmarks.
Security: Audit security practices and access controls. This is critical when dealing with sensitive data.

Evaluating against these key focus areas will help you choose a cohesive DevOps toolkit for Kubernetes. Prioritize capabilities that map to your specific workflows and constraints. This thoughtful selection process leads to long-term efficiency gains, optimized workflows, and getting the most from Kubernetes.

Conclusion

Kubernetes has become the leading platform for deploying containerized applications at scale. However, to fully realize its benefits depends on adopting the right set of Kubernetes DevOps tools and workflows.

This guide provided an overview of the most essential Kubernetes DevOps tools across CI/CD, deployment, monitoring, automation, and other areas. While Kubernetes solves major technology challenges, complementary tools address processes and collaboration.

By leveraging solutions like Jenkins, Helm, and Datadog, teams can optimize productivity and application quality. Adopting this new DevOps toolkit tailored for Kubernetes will accelerate your software delivery.

The variety of options also means evaluating your needs, environment, and constraints before choosing solutions. Focus on capabilities, integration, usability, and community support during assessments.

This new generation of purpose-built Kubernetes DevOps tools represents a turning point for optimizing Kubernetes productivity, resilience, and delivery.