|Hacker News, Reddit, Stack Overflow Stats|
No public GitHub repository stats available
|Description||An open source project to pack, ship and run any application as a lightweight container||App Container runtime||Share, discover, and create Vagrant environments|
|Why people like using this service||
|Companies using this service|
Docker is the Future
May 29, 2014 20:45
Docker is the new kid on the block disrupting virtualization nowadays. You're able to save up to 70% of your development cost on AWS (or any other cloud) switching to Docker. For example instead of paying for many small VMs you can spin up a large one with many Docker containers to drastically lower your cost. That alone is only one of the reasons why Docker is the future and it's not even the best feature: isolation, testability, reproducibility, standardization, security, and upgrading / downgrading / application versions to name a few. You can spin up 1000's of Docker containers on an ordinary Laptop, but you would have trouble spinning up 100's of VMs. If you haven't already checked out Docker you're missing out on a huge opportunity to join the movement that will change development/production environments forever
Rapid stand up of related services for testing while enabling artifact creation of services for promotion to prod.
We are testing out docker at the moment, building images from successful staging builds for all our APIs. Since we operate in a SOA (not quite microservices), developers have a dockerfile that they can run to build the entirety of our api infrastructure on their machines. We use the successful builds from staging to power these instances allowing them to do some more manual integration testing across systems.
Using Docker for all recent web projects, both in development (with Docker Compose) and in production.
been using docker extensively for the last 2-3 years. great for setting up an environment quickly. makes using services like reddis/postgres/rabbitmq a breeze.
→ My Stack
Production, development, at home if I need anything it will be in docker. In conjunction with digital ocean if I need real isolation
가성서버에 어플리케이션을 만들면 관련 인프라 서버 디비 등을 다 설치 해야 하는데 더이상 필요없다고 느끼면 일일히 지우기도 번거로웠다. 게다 깔끔히 지울줄로 몰라 아쉬웠는데 어플리케에션 인프라와 어플리케이션은 컨테이너에 격리해 관리 할 수 있어서 생성 및 삭제가 쉬었다. 써보고 혁신적이다라는 생각이 많이 들었는데, 실무에 사용할 일어 없어 아쉬웠다. 실무에서 꼭 적용 시켜보고 싶은 것중 하나이다.
Docker let's us scale up and down the amount of web servers we need to meet demand of our users. It also allows really isolated environments which causes less errors when moving from our dev machines over to production.
I use docker on Mesos/Marathon/Zookeeper Frameworks among GCE/AmazonEC2/AliCloud ... for application deployment.
I also create Dockerfile for build a image. Such as TomEE, MongoDB.
Our new product at IndideSales.com is built in Docker, from development through production. Everything is "Dockerized"!
Allows anyone to work on my project with the same development environment. Using docker-compose, I can get an app running in a few minutes. Also have used it for deployment.
Docker is a core component of our microservice platform. User services usually consist of multiple Docker containers linked together. Also all underlying services are running inside Docker containers.
The default deployment mechanism for Web Apps built in Agile Toolkit uses Docker / Dockerfile.
You take a docker image of an OS, and then you add your application artifacts to it. BOOM! Magic.
Docker is more impressive tool in action on this stack. With little knowledge, docker improve management, and portability of all infrastructure on this adventure. Many Containers cooperating one with other to solve business and scalability challenges.
Handles running of all services from frontend load balancer to database servers.
The system will be deployed to our customers' data warehouses with no Internet connection. Therefore, a simple deployment tool is necessary.
Each component of the app was launched in a separate container, so that they wouldn't have to share resources: the front end in one, the back end in another, a third for celery, a fourth for celery-beat, and a fifth for RabbitMQ. Actually, we ended up running four front-end containers and eight back-end, due to load constraints.
We use Docker both in development (100%) and in production - everywhere except the user-facing frontend which runs on Heroku.
→ My Stack
When complete software stacks are needed, I prefer docker instead of installing all of the individual components on my own. Example: ELK stack, Grafana-InfluxDB stack, sentry-postgres-redis stack.
Docker containers are deployed on top of Mesos using Marathon to isolate failure and ensure portability.
The various components of the internal applications are deployed in containers, kept in isolation so that we can easily update some components without interfering with others. This is low cost and fast compared to virtual machines.
Our microservices are packaged as Docker containers for easy deployment and management (especially dependency management where some services require different versions of Node.js than others).
If there's any platform that's better built for sandboxing, it's Docker. The container infrastructure and Salt have allowed us to build a secure production infrastructure insanely fast from scratch.
Docker helps us make our development and production environments as close to the same as possible. This improves our deployment times to seconds.
All my sites are packaged as Docker containers, to simplify deployment and local development.
Publishing docker images to a docker registry can't be done without docker so that's why it's here.
We use Docker everywhere. Every new service is built in Drone into a Docker image and pushed to our Dockerhub tagged with the git hash. We can then have full confidence we are deploying the exact version of any service.
Enables easy operation of both development and production environment, also to make the project reproducible.
We are running primarily as a micro-services platform and Docker lets us iterate on these smaller units consistently from dev to staging to production. It is also integral to our continuous deployment system for rolling out or rolling back new features.
Currently experimenting. The idea is to isolate any services where I'm not confident yet in their security/quality. The hope is that if there is an exploit in a given service that an attacker won't be able break out of the docker container and cause damage to my systems.
An example of a service I would isolate in a docker container would be a minecraft browser map application I use. I don't know who wrote it, I don't know who's vetting it, I don't know the source code. I would feel a lot better putting this in a container before I expose it to the internet.
I believe I will follow this process for anything that's not properly maintained (not in an trusted apt-repo or some other sort of confidence)
I have a manifest to setup a Docker container before I have a Dockerfile. I'm still trying to figure out my preferred method of deployment, so in the meantime I figured I should try different methods to make an informed judgment.