docker container to talk to Kubernetes Cluster

There could be need to talk to Kubernetest cluster from segregated docker containers. It’s possible to do so:



build the pipe from the container to the host machine

There are several ways to connect the host machine. the container is running together with the host, behaving like on the same subnet. you can access it through the public IP.

otherwise, more elegantly, you can leverage on host.docker.internal to talk to the host


proxy the resources for the Kubernetes cluster

you can start a Kubernetest proxy to talk to the cluster.

kubectl proxy --port=8080 --disable-filter &



then to talk to the resources in the cluster from the container, you can do



access the parent docker daemon from the container

recently i have a need to build/start/stop some sibling containers (vs docker within docker), the way to do it is to expose a pipelien from the host to the container:

for single container:

docker run -v /var/run/docker.sock:/var/run/docker.sock

for docker compose

image: xyz
context: .folder/to/the/controller/container/image
- 5000:5000
- ./:/app
- /var/run/docker.sock:/var/run/docker.sock

View at

actually the dameon could listen from other host (configuration):

update dockerfile within docker compose

have encountered some issue with the stale dockerfile. turns out, docker compose actually cache previous builds (this is not stated in the doc).

so to keep it updated, need to run build without cache then bring it up.

docker-compose build --no-cache && docker-compose up

publish vscode extension with bundled in images/gif

its by default vscode expect a public git repository for referring the code and even images to be shown in the markdown.

an alternative, workable solution to enable for the bundled in images is through publish a pre-packaged vsix.

You can override that behavior and/or set it by using the –baseContentUrl and –baseImagesUrl flags when running vsce package. Then publish the extension by passing the path to the packaged .vsix file as an argument to vsce publish.

Tools & Dev Ops & Middleware

1. ivy vs maven
Ivy is dedicated as a repository for dependency hosting/management. Ivy is normally working with ant.
Maven is more than dependency management, however, has become one of the most popular dependency repository.

2. make vs ant vs maven vs gradle

make is the dinosaur age build tool, was since 1960s.
ant is also dedicated build tool, which create “target” to run using the ant libraries (java).
maven has another hat of being a build tool. it starts with settings.xml(the repository locations) and pom.xml (the individual configuration for project).
one advantages maven over ant is, maven has defined a lot conventions (which become kind of standard and provides a lot convenience, similar to spring’s being “opinionated”.) so instead of telling ant, where is the class & resources to compile from and into, maven comes with default compile command which works unless you have different than convention folder structure, (which then can be simply configured in pom.xml to tell maven).

|   +---main
|   |   +---java
|   |   |   \---com
|   |   |       \---best2lwjj
|   |   |           \---services
|   |   |         
|   |   |                   
|   |   \---resources
|   \---test
|       +---java
|       \---resources

gradle a new challenger, which features groovy scripts instead of xml. (build.gradle & settings.gradle) which provides “unlimited” functionality conveniently. (instead of build a library or maven plugin, build.gradle can be written using a full functioning groovy language.)

3. CD & CI: jenkins vs hudson
both actually come from same origin. Hudson is first started by SUN (before being acquired by Oracle many years back). It was open source before.
After oracle bought over, the open source community since has moved to create Jenkins from the same original source code. (Jenkins become way more popular now.)

both and same as other CI & CD tools basically polling the source code repo (being svn, cvs or git); then take corresponding actions (configurable), such as ant compile/maven build/gradle integration testing etc….

4. CI & CD with gitlab
git become more and more popular. (git being another project from the Linus Torvalds, has borrowed a lot, like file system from Linux.)

one difference from other CI tools, gitlab enables customized gitlab runner, which is a dedicated server/servers to run certain tasks (configurable through tags). this creates a lot possibilities.
for example, one thing i have done in goldman was, to create a new pipeline, which was able to pick up code changes from feature branch, compile, test, integration test, build, package, put onto cloud/repository, deploy it and restart the server. all in one go, without single manual intervention.
This become possible with the gitlab tags and runners.

5. gitlab
normally master/ rc-xx / release-xx are feature branches, which are protected and monitored for automations/CI/CDs.

6. common issue with maven dependencies

Image vs Containers for Docker

Not many developers explain technologies clearly, either intentionally or incapably. the post here however is one exception:



IMAGE :- An image is an inert, immutable, file that’s essentially a snapshot of a container. Images are created with the build command, and they’ll produce a container when started with run. Images are stored in a Docker registry such as Because they can become quite large, images are designed to be composed of layers of other images, allowing a miminal amount of data to be sent when transferring images over the network.
 CONTAINER :- To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object. Containers are hopefully why you’re using Docker; they’re lightweight and portable encapsulations of an environment in which to run applications.