We are working on T160K https://t160k.org/ which is crowdfunding sustainable and meaningful development in Africa by focussing on arts and culture. Another goal of the project is to promote a positive and vibrant image of African culture through our campaigns and messaging. One of our projects that initially got me excited about the idea is the Timbuktu Libraries in Exile https://t160k.org/campaign/libraries-in-exile/
It could also be just part of our zeitgeist and the link you are making is coincidental and not influenced or paid for by shark tank's investors. I think to prove that there is a shark tank connection, you need to research the author's bio a bit more, article history, and prove that this author repeatedly writes pseudo articles that are marketing pieces... and you have not done any of that research.
Docker, CoreOS, and the entire ecosystem are moving really fast, it is a bit hard for me as a developer to keep up. For some projects we are creating containers with Docker and will need to get some things into production as soon as Docker 1.0 is declared stable.
At the same time I want to switch to CoreOS, I also want to wait just a little while for blogs, tutorials, and tools to catch up to where CoreOS and Docker are at, and be usable in production by people who are not professional devops.
The most exciting thing for me in this post is CoreOS CloudInit. It seems to be one of those tools that a small shop could use. It looks a bit like the yaml for fig, but is something that could be used in production as well. At the moment, I have been trying to solve everything a bit on my own with Makefiles, which include Makefiles for custom variables and Makefiles for commands that can be run against each container. It is working great for dev, but I could never really see how to run the containers in prod. The Makefiles didn't really seem like a prod solution, but CoreOS CloudInit looks like it could work.
We also skipped boot2docker and use vagrant with ssh, so seeing that there is a Vagrant box which will run just like an EC2 box is pretty exciting. I would be excited if Digital Ocean would start supporting CoreOS too.
You will save so much time developing node if you install Ubuntu with virtual box and vagrant. All are free, and then you can really participate in the os world without having to hack everything to work on windows.
I've started using Make to build and run docker containers in the dev environment. It's not the perfect tool, and neither are my skills that great with Make, but it sure gets the job done and enables docker commands to be shared between devs. For example this Makefile (still under development) for PostgreSQL https://github.com/GlobAllomeTree/docker-postgresql/blob/mas...
To be clear - I think FreeBSD is an awesome project and the jails look solid, but it is really the Docker community and exploding Docker ecosystem that makes Docker appealing to me. For example, Red Hat embracing Docker means that I can build Docker containers for enterprises that embrace CentOS and Red Hat. None of the corporations or organizations I have worked with use or support FreeBSD, but they all support CentOS. Reference: http://www.infoworld.com/t/application-virtualization/red-ha...
If your past 5 comments have not gotten more than 3 cumulative upvotes from ranking users then your commenting is throttled to 1 comment per day
If your past 5 comments have a cumulative negative score your commenting is limited to 1 comment per week
There is no pending comments list, only a message telling you: sorry, try to post higher quality content to be able to comment more often. You will be able to post another comment tomorrow / next week
New users are limited to one comment per day until they get at least 3 cumulative upvotes in the last 5 comments
I am still finding good solutions for those too, and trying to add some concepts to my toolbox like orchestration, service discovery, proxies, data containers, ambassador containers, and so on. It's hard for me to wrap my head around the different recommended ways to use docker compared to my initial expectations.
This is a great point. The initial Docker examples make everything seem easy, but we blew way past our estimated time in integrating docker into our workflow because of the points you mention. I am still happy with the choice to use docker though and our team will be better at server administration in the future.
One thing about this getting started guide is that it recommends the Phusion base image which boots init. That seems to go against the best practices outlined in a recent article by Michael Crosby - http://crosbymichael.com/dockerfile-best-practices-take-2.ht...
I think its important to realize that is can take years to reach a goal, maybe 10, maybe 15. Many people work to change or better the world for their entire lives while only viewing change in the smallest ways. It's not a realistic expectation that you will generate something world changing in the span of a year, or even two. So to be happier you need to learn how to enjoy yourself while you work and learn, whatever it takes.
Learning how to manage yourself and your life is one of the greatest keys to completing a project. If you are successful in your world changing idea, but you have not learned to manage yourself, how are you going to manage other people? Start out by training yourself as a manager with your first employee - yourself. You would not want a boss that worked you night and day with unrealistic expectations. So - don't be that boss. You can be hard, but reward yourself too. And give yourself the time it takes to really learn.
Personally happiness for me includes going to the gym daily, sleeping well, eating well, and seeing family. And I'm getting closer to some of my goals than ever before. When I worked myself late into the night and didn't eat well, I actually saw my goals slipping away since I was no longer managing myself in a direction that would actually bring about the goals I had set. Maybe I was chasing after short term deadlines, but not really striving toward life goals. Now after 14 years of programming I am coming back to some of my original ideas with a totally different perspective that actually holds a lot more real world value.
The benefits of me that docker brings is the ability to share containers with my team and to deploy those same containers to the server. The reason that I started thinking of it in terms of programming, like OOP, was to help me get my head around how to correctly use docker on a server. As I start to understand docker, finding the correct place for configuration, data, crons, debugging, and execution are all important and the closest paradigm that I can easily apply to it is OOP, even though it is not a perfect match. OOP can also help visualize how one image can inherit from another image and override both methods and configuration of that image so that instances will behave in a different manner.
Docker is a container for running processes, or a process. Containers should be disposable and transient. I have begun to think of it in terms similar to OOP. Images are your Classes. Containers are your class Instances. When you are done with an instance, you discard it and make a new instance. So don't go shoving all kinds of crap into the instance like crons and sshd that don't belong there. Most devs don't expect to have their code be free of memory leaks when it comes to interpreted languages. And docker containers don't need to worry about child processes being stopped - they should just be disposed of and you make a new container from your image. Keeping containers around would be like trying to pickle a python class instance perpetually that has references to who knows what... Just make a new instance when you need it. And just make a new container when you need one. I use named containers and a Makefile that stops and deletes existing containers with the same name before starting a new one.