I tried it out last time it showed up here. IIRC everything was tied to the registry (couldn't use my own non published images) so I went back to just using boot2docker.
I'm using it. Took a little wiggling and getting used to, but so did Boot2Docker. Overall, I think it's buggier and less mature, but more capable. The GUI output and log views are handy for quick debugging of obvious problems.
I wanted to use Kitematic as a way to get our non-CLI savvy designers up and running with our software stack on docker. They key feature missing IMO is the ability to "open" a docker-compose.yml file.
I want the ability for a designer to select "file open" and then select the docker-compose.yml file to "launch" our stack.
Without that, it seems like you still need to rely on the docker-cli to build images from a Dockerfile.
My first job was at a call center where we trained literally anyone who applied to use command line DOS to take orders for sausage over the phone. This took three days to teach these people how to navigate a pretty extensive CLI interface. Many of them were highschool dropouts with GEDs. If they even attempted to use the mouse the computer would lock up. We had virtually zero issues.
It's astonishing that some people refuse to even open a terminal.
They currently do, but some prefer a UI to manage the containers, and since we're using OSX, making sure boot2docker and the underlying VBOX image is in a good state can sometimes cause a few wrinkles that take a developer to straiten out.
Kitematic could abstract that layer (boot2docker) away with a GUI.
You're using Docker Compose on Mac? I tried when it was still called Fig, and while it was wonderful for simplicity, the filesystem performance for VirtualBox/boot2docker made it brutal to use. My Rails apps in development mode (therefore serving up many individual assets) would take almost a minute to load each page.
Has it gotten better, is there a trick you're using, or am I hitting an edge case you don't have?
I really don't think so. You might just be underestimating the number of static asset files in a client-heavy web app before concat/minify ever happens. Watching the logs, you could see... each... little... file... take... way too long.
No, we ran into the same issues. When dealing with mid-sized Node.js projects in particular where the dependency tree may include something like 70k source files. `npm install` can take several minutes, builds on-save could take several seconds. We resolved to simply doing everything inside of a VM, using sshfs to "persist" the data out to the host machine on-demand for those uncomfortable using vim/tmux inside the VM.
This landing page fails the "what is it?" test. Seems like I might want this since it involves Docker and Macs, but I still don't know what it is. Yes, there's a video, but you should not have to watch a video to know what something is; worse still, the video doesn't even tell you what Kitematic is – it just tells you that it "helps you get started with Docker". Ok...
What's your motivation for pointing this out? Just curious.
Do you want people to go talk about it on the other thread instead of this one? Or, are you trying to keep duplicate posts or comments off of HN? Or, something else?
When a story has had significant attention in the last year, it counts as a duplicate (otherwise a small number of reposts is OK; see https://news.ycombinator.com/newsfaq.html). It's helpful when users point out the ones we've missed.
I'll just go ahead and take the downvotes for suggesting that people who want to use Linux-technology, like Docker, within their OS should just use Linux as their OS.
Yeah. Call me crazy, but I honestly think that makes a whole lot of sense.
I will play devil's advocate to your comment and say that it's my impression that the benefits of Docker are such that I can use whatever I want, including OS X, and let the containers be whatever OS suits them. So if I want to do my primary development on a Mac but my prod environment is CentOS, it doesn't really matter since my container is Ubuntu anyway. And I get to use my nice, native toolchain for development, like BBEdit, or whatever I really want.
But containers aren't completely isolated. In particular, they share a kernel with the host OS. (And the file system, I think?) So you need to have software built with the right system calls, not to mention compiled for the right hardware architecture.
I think you are confusing containers and VMs. Containers use the kernel from the hosting machine, so if you want to use a container on a non-native host, you have to use a VM.
VM technology is advanced enough that you can do development on a non-native platform, but it won't be quite as smooth, and adding containers on does complicate things quite a bit, because you now have a container running in a VM running on the native platform, having to deal with three layers of networking etc...
Well, they more or less are, but in a VM. It's what I do from my Windows desktop dev box. When I'm working at my Fedora workstation, again, everything lives inside a VM so that I don't accidentally pollute my target environment, or my workstations.
Some of us that use Mac applications don't like to break the law and run OS X in a VM when that is not allowed by the license agreement. You can run it in a VM if your host OS is OS X, but not if it is Linux.
I use OS X with VMware fusion and am very happy with it. I can run the commercial apps I need plus Linux, Windows, docker...
> people who want to use Linux-technology, like Docker
What defines Docker as 'linux technology'? It has an execution driver API specifically designed to support multiple backends, e.g. BSD jails. I wouldn't use the fact that they started with linux support to declare them 'linux technology', whatever that means.
Docker is a "Linux Technology" because it is based on a particular feature of the Linux kernel (http://en.m.wikipedia.org/wiki/LXC) and you need to run a Linux kernel (either in a vm or on bare metal) to run them.
LXC isn't a 'feature of the linux kernel' it's a user land library that uses a set of linux kernel features (e.g. cgroups, namespaces, etc) to expose an api for creating system containers. LXC isn't part of the kernel.
Docker's default driver has been libcontainer, not LXC, for almost a year. libcontainer implements Docker's execution driver api and works with the various linux kernel features needed to implement containers directly, it doesn't use LXC at all.
Docker isn't based on nor reliant on LXC in any way anymore and with the execution driver api is designed to run on various platforms.
I would be developing in containers (I use both Vagrant and Docker) even if I were using Linux rather than OSX for my desktop. Why? Repeatability. I can automate and fully control my development/deployment environment with containers, something I can't do with a desktop machine.
Day-to-day desktops and laptops are snowflake servers, if you use them for server development. Developing on them, without a container layer, is begging for all the problems of snowflake server development and deployment, all the things we've been trying to get away from in the second decade of the 21st century.
If I'm not misunderstanding you, you're calling for a retreat to development practices I don't want to use, development practices that are demonstrably harmful. And if I do understand you, then there's absolutely no benefit to using Linux rather than OSX for my desktop, because I'm containerizing anyway.
So no, not downvoting you. Just showing you why you're wrong.
And that's why I rent servers from digital ocean or linode. However, nobody has yet written http://selfcontrolapp.com/ for OS X but they have written xmonad (the thing that was keeping me on desktop Linux) for OSX.
And no, I can't write self-control on Linux for myself, because then circumventing it to read the news wouldn't require more patient thought than whatever I'm trying to focus on. Please don't discuss how it works in replying to my comment. I want not to know.
Never heard of SelfControlApp but looking at it, it might be just what I need since I just started working remote a few months ago. Thanks for the link!
Why would I restrict myself to Linux if the tooling I prefer is only available on Mac? I guess if my entire workflow was terminal based then Linux would make sense but I'm more productive with Intellij, Kaleidoscope, Tower Git, iTerm, and my iTunes library of music. A vm running centOs and using docker let's me use my favorite tools and still leverage Linux as a deployment environment, how does that not make sense?
IntelliJ, Git, and music-listening developr here. On GNU/Linux.
It does not make sense because you stop yourself from knowin the inner workings of what you are targeting in your development efforts - eat your own poison so to say - CentOS - run CentOS. How hard can that be?
Or just go the other way around and let your toolchain reside on the host and your source code reside on a VM. I've always found that to be a more natural workflow: my VM remains a more pristine true-to-production environment and I'm not stifled by the oddness of doing 90% of my work in a virtual environment.
B. Tower, Kaleidoscope. iTerm, and XCode are all Mac only
C. How in Earth do you draw the conclusion that I've stopped myself from knowing anything? I am running CentOS, in the VM. I'm extremely familiar with the inner workings of Linux. If I'm running in a VM or as the main OS has no bearing on how much I know about my deployment target. It's still the same steps to setup a deployment target VM or on my actual laptop. In fact in the case of AWS you could argue that a VM is much closer to my deployment prod servers than laptop hardware would be.
According to Apple and the License agreement you agree to run Mac OS X. It requires apple hardware to run the OS in the agreement. Perhaps you should read something prior to calling someone else out.
2. Permitted License Uses and Restrictions.
A. This License allows you to install and use one copy of the Apple Software on a single Apple-labeled computer at a time. This License does not allow the Apple Software to exist on more than one computer at a time,and you may not make the Apple Software available over a network where it could be used by multiple computers at the same time. You may make one copy of the Apple Software (excluding the Boot ROM code) in machine-readable form for backup purposes only; provided that the backup copy must include all copyright or other proprietary notices contained on the original.
d00d, I was running Slackware on 0.9 kernels in a business environment when half of HN was trying to figure out how to remove their own diapers. I know Linux quite well enough. I use OSX for my desktop because it's the least awful desktop experience. If I'm coding, it's mostly command line tools, and there is no technical difference between running bash on a Linux desktop and running bash via vagrant ssh on my Mac.
What is different is that my Vagrant instance configuration is 100% programmable and repeatable. There are no surprises. There are no differences between development environment and production environment, in terms of installed software or patches. I'm not hacking away on some snowflake environment and then trying to grok wtf is wrong with my code when it gets deployed to the next environment.
But the original post isn't about this, even... it's about Docker. Dockerized applications are 100% binary-level compatible from environment to environment. I can easily localize from dev to test to production using environment variables - a proper 12 Factor App. Why would I not want to do this in my development environment? Why would I go back to some crude 2003-vintage development model that I know good and well is going to break things later?
And it gets worse. Lots of us have to deal with heterogeneous environments. What if I'm building for both CentOS and Debian? With something that's OS patch-sensitive? Do I test in production to see if it survives? No, I use Vagrant to test every platform I want, and Docker to guarantee consistency whenever I can.
How hard can it be? It can be much, much harder than a proper, modern Vagrant/Docker environment.
]I've regularly experienced issues with not the development system not being the target system _within linux distros_. Just go the whole way and develop with the target environment isolated from your host system.
You're not running Linux, you are running _some version of Linux_.
I tried Kitematic briefly and it seemed fairly buggy. I also was getting some kind of conflict between it and the command line tools with boot2docker. I just stopped using it and moved straight to boot2docker.
Your other options on Mac are Vagrant's docker provider -- which is nice, but I agree in general with the sentiment that it is even nicer to just use Linux natively.
I've quickly looked at the app(0.5.18), great improvements from 0.2 version! One quick feedback, you can implement in-app browser for browsing images(atm you are being kicked out of the app).
61 comments
[ 2.5 ms ] story [ 124 ms ] thread500 server error - No command specified
I want the ability for a designer to select "file open" and then select the docker-compose.yml file to "launch" our stack.
Without that, it seems like you still need to rely on the docker-cli to build images from a Dockerfile.
My first job was at a call center where we trained literally anyone who applied to use command line DOS to take orders for sausage over the phone. This took three days to teach these people how to navigate a pretty extensive CLI interface. Many of them were highschool dropouts with GEDs. If they even attempted to use the mouse the computer would lock up. We had virtually zero issues.
It's astonishing that some people refuse to even open a terminal.
Kitematic could abstract that layer (boot2docker) away with a GUI.
Has it gotten better, is there a trick you're using, or am I hitting an edge case you don't have?
We haven't had a problem since the Docker 1.3 update.
VirtualBox filesystem performance isn't amazing, but it isn't anywhere near that bad. There was probably another issue involved here.
But I think it's disingenuous to say this landing page doesn't explain what it is.
Do you want people to go talk about it on the other thread instead of this one? Or, are you trying to keep duplicate posts or comments off of HN? Or, something else?
Yeah. Call me crazy, but I honestly think that makes a whole lot of sense.
VM technology is advanced enough that you can do development on a non-native platform, but it won't be quite as smooth, and adding containers on does complicate things quite a bit, because you now have a container running in a VM running on the native platform, having to deal with three layers of networking etc...
I use OS X with VMware fusion and am very happy with it. I can run the commercial apps I need plus Linux, Windows, docker...
What defines Docker as 'linux technology'? It has an execution driver API specifically designed to support multiple backends, e.g. BSD jails. I wouldn't use the fact that they started with linux support to declare them 'linux technology', whatever that means.
Docker's default driver has been libcontainer, not LXC, for almost a year. libcontainer implements Docker's execution driver api and works with the various linux kernel features needed to implement containers directly, it doesn't use LXC at all.
Docker isn't based on nor reliant on LXC in any way anymore and with the execution driver api is designed to run on various platforms.
Day-to-day desktops and laptops are snowflake servers, if you use them for server development. Developing on them, without a container layer, is begging for all the problems of snowflake server development and deployment, all the things we've been trying to get away from in the second decade of the 21st century.
If I'm not misunderstanding you, you're calling for a retreat to development practices I don't want to use, development practices that are demonstrably harmful. And if I do understand you, then there's absolutely no benefit to using Linux rather than OSX for my desktop, because I'm containerizing anyway.
So no, not downvoting you. Just showing you why you're wrong.
http://ianyh.com/amethyst/
And no, I can't write self-control on Linux for myself, because then circumventing it to read the news wouldn't require more patient thought than whatever I'm trying to focus on. Please don't discuss how it works in replying to my comment. I want not to know.
IntelliJ, Git, and music-listening developr here. On GNU/Linux.
It does not make sense because you stop yourself from knowin the inner workings of what you are targeting in your development efforts - eat your own poison so to say - CentOS - run CentOS. How hard can that be?
B. Tower, Kaleidoscope. iTerm, and XCode are all Mac only
C. How in Earth do you draw the conclusion that I've stopped myself from knowing anything? I am running CentOS, in the VM. I'm extremely familiar with the inner workings of Linux. If I'm running in a VM or as the main OS has no bearing on how much I know about my deployment target. It's still the same steps to setup a deployment target VM or on my actual laptop. In fact in the case of AWS you could argue that a VM is much closer to my deployment prod servers than laptop hardware would be.
According to who? Has this been tried in a court of law?
If not, it's legal until proven otherwise. This BS by Mac-appologetics has got to stop.
2. Permitted License Uses and Restrictions. A. This License allows you to install and use one copy of the Apple Software on a single Apple-labeled computer at a time. This License does not allow the Apple Software to exist on more than one computer at a time,and you may not make the Apple Software available over a network where it could be used by multiple computers at the same time. You may make one copy of the Apple Software (excluding the Boot ROM code) in machine-readable form for backup purposes only; provided that the backup copy must include all copyright or other proprietary notices contained on the original.
from: http://store.apple.com/Catalog/US/Images/MacOSX.htm
What is different is that my Vagrant instance configuration is 100% programmable and repeatable. There are no surprises. There are no differences between development environment and production environment, in terms of installed software or patches. I'm not hacking away on some snowflake environment and then trying to grok wtf is wrong with my code when it gets deployed to the next environment.
But the original post isn't about this, even... it's about Docker. Dockerized applications are 100% binary-level compatible from environment to environment. I can easily localize from dev to test to production using environment variables - a proper 12 Factor App. Why would I not want to do this in my development environment? Why would I go back to some crude 2003-vintage development model that I know good and well is going to break things later?
And it gets worse. Lots of us have to deal with heterogeneous environments. What if I'm building for both CentOS and Debian? With something that's OS patch-sensitive? Do I test in production to see if it survives? No, I use Vagrant to test every platform I want, and Docker to guarantee consistency whenever I can.
How hard can it be? It can be much, much harder than a proper, modern Vagrant/Docker environment.
I thought that was pretty obvious, but looking at the response I guess not.
You're not running Linux, you are running _some version of Linux_.
Your other options on Mac are Vagrant's docker provider -- which is nice, but I agree in general with the sentiment that it is even nicer to just use Linux natively.
I hope they will fix it soon.