The function of habitat

I have used habitat for a couple of days, but I confused about the function of habitat.
Now I think it is a tool for packaging, the workflow is like this:
①Write a plan file and config files
②Build it and generate a hart file
③Export to any kinds of package which you wanna use(such as docker,k8s)
My questions are:
First, ①②③are full fuction of habitat? We couldn’t do anything else?
Then if I only use the platform of docker, I needn’t to use habitat, because it’s more convenient to write a dockerfile instead of plan and config files, right? In the case we use docker and k8s and mesos and…, I will
be more convenient when use habitat?
Second, we packaged a hart file in a laptop, but when I sent it to another laptop, it can’t be used directly, so
if we wanna migrate it to another laptop, the most important thing is plan file instead of hart file?
Third, after I installed ‘Docker for windows’, it generated a linux vm with hyper-V. Habitat now have the function of exporting a Windows package to a Docker Windows container, is it in conflict with the linux vm in hyper-V? Because habitat can’t export a windows package to a linux container, right?
I do hope some one can help me solving those puzzles, Thanks!


Glad you’re trying out Habitat!

I wrote a short blog post about what habitat is, here:

Have a read through that, it explains what I think are the 3 main features of Habitat.


Speaking to the Docker for Window question, the container os depends on your Docker settings. If you right click on the docker icon in your desktop tray, you will see a “Switch to Windows Containers…” or “Switch to Linux Containers…”. By selecting that option you can toggle back and forth between Windows and Linux containers.

So if you want to export to Windows containers or enter a Windows Docker Studio, make sure you are switched to Windows containers.

I only deploy Habitat packages to Kubernetes. I could use plain Dockerfile-built images, but here’s why I use Habitat:

  • Dependency management. I always know every version of every dependency installed in a habitat-exported docker image. This is not so easy with standard Dockerfiles based on some base OS image. This makes security audits super easy and my auditors happy.
  • Consistent and repeatable builds. Plan builds are much more flexible than Dockerfiles.
  • Consistent configuration interface for all services. I keep all my service configs in a set of YAML files and use a tool to convert to TOML and apply to Kubernetes. No one-off configs or formats for any of my 10+ services.
  • Runtime lifecycle management (hooks like post-run, health-check, etc.) and service discovery (binds). Having this consistent for all services has been a huge operational win and makes reasoning about changes or problems much simpler.

Thank you! I had found the bottom you said.

Thank you!!! I’ve read all your blogs about habitat, and knew the main role of habitat, it’s a package tool and we can transform it to the format of a container platform. But I wanna ask a question about it. The way we package and deploy is all by hand? Could Habitat combine with other tool to realize CI/CD?

It’s very kind of you! And I’d like to enquire another thing, in the third point of your answer, you said you put all service configs to a set of files and final apply to K8s, is it a automatic process or something like CI/CD? Because in the references of Habitat, I found we package and export by hand instead of antomatic, maybe it’s not convenient for a product environment. Should I combine Habitat and other tool(like Chef?) to realize CI/CD?

I’m using Jenkins to build, export, and deploy my Habitat packages into Kubernetes. There are many ways to approach CI/CD like using many different tools. I’m only using Jenkins because it’s what me and my team are familiar with it. Habitat Builder also provides the build+export functionality that might work for you.