7 ms·

Ask HN: As a web developer, do I have to know what Docker and Kubernetes are?

• sd8dgf8ds8g8dsg 9y ago
  Using docker can greatly improve your development situation. For example, you can use docker to define the full environment needed to run your web app, meaning you can have another dev running it with "docker run", and not needing to install any local dependencies, as everything (web server, node etc) is contained inside the docker container. This turns out also be useful for your future self, when you in 2 years from now are having troubles re-creating the environment needed for running your service. Docker orchestrate can further improve your development situation, in which you can use it to define and test out multiple virtual servers on your laptop, such as the database, the file server and the web server.
  • stephenr 9y ago
    Quite honestly Vagrant will do all of that for development.
    • sumedh 9y ago
      Setting up containers is ridiculously fast compared to VMs.
      • stephenr 9y ago
        What do you mean by "setting up". Are you talking about the work to provision a working target environment (i.e. what the VM/Container runs) or are you talking about the literal time for the environment to start?
        • viraptor 9y ago
          Containers help with both. No full-system boot delay helps. Cached layers help. Not dealing with vm-specific kernel modules helps. Fast non-nfs volumes shared with the host help. There are speed benefits for containers all over the place - both in time spent dealing with the environment and in actual execution.
          • stephenr 9y ago
            > No full-system boot delay helps I just cold-booted a Vagrant VM, which is configured to check for new base-box versions (i.e. a network delay that can be disabled). time vagrant up ... real 0m39.698s user 0m11.989s sys 0m5.490s If your argument about tooling is around performance and the "slow" one takes just 40 seconds to start, I think you need to clarify how often you expect to be starting this tool in a day. > Cached layers help. Helps what, exactly? > Not dealing with vm-specific kernel modules helps. I don't even know what you're talking about here. Do you mean you need to have a hypervisor kernel module? What exactly do you need to "deal with"? > Fast non-nfs volumes shared with the host help. I've never once used an NFS volume in a Vagrant guest. In case you weren't aware, Vagrant is not limited to using VirtualBox. > There are speed benefits for containers all over the place - both in time spent dealing with the environment and in actual execution. You haven't actually identify any environment issues you need to "deal with", just said "X helps".
            • viraptor 9y ago
              Some context then. The happy path startup cost (environment is already prepared) matters to devs who never deal with the environment itself. If you're dealing with frontend only - maybe that's you most of the time, and you only see the 40s maybe once a day. But there are other costs. Someone deals with updates, with adding new functionality, with debugging issues. I spend most of my day recently waiting for puppet runs in vagrant/vbox. It's 10+ min for a full run. Then I make more changes - sometimes an incremental provision is enough, sometimes I need a full rebuild. On the other hand, if the environment was built with docker layers, I'd have much less waiting to do, because the caching of partial build/layer is integrated. Over a whole day, that's not insignificant time saving. And sure, vagrant has multiple backend. I'm using vbox, and so does almost every developer using vagrant. It's the only free one. (Apart from the docker backend)
    • mickeyp 9y ago
      Yes, with the caveat that if you already use a hypervisor for your main dev environment then running another inside it with Vagrant's default VBox setup is likely to either be very slow or not work at all. Docker will also layer and cache each command greatly speeding up the "build&test" cycle of writing and running Docker containers. With Vagrant you're re-running everything every time. Furthermore, you can actually use Docker with Vagrant also nowadays.
      • stephenr 9y ago
        This sounds like a rare scenario, much more common these days I believe would be a non-Linux host, with a Linux "guest" server environment. If you want to use Docker, you're then automatically using a hypervisor anyway. > With Vagrant you're re-running everything every time. Are you talking about the time to provision a non-created environment? On a clean install, sure, that might take a while if your base-box doesn't have the dependencies you require - but most developers wouldn't often need to re-build their Vagrant environment for a project from scratch (i.e. vagrant destroy is not likely to be a common task). And that whole situation is moot if you use or build a more appropriate base box.
        • mickeyp 9y ago
          Is it that uncommon? Mac users using a hypervisor? Windows using running Linux in a Virtualbox? That's pretty common in corporate environments... I am talking about rebuilding the Vagrant image every time you change it - as you are wont to do during the initial step of creating it. Sure, once it's written (by someone who has to spend a fair amount of elapsed time doing trial-and-error tweaks) then you don't have to re-cycle the image. On the other hand, that too can result in people using stale images over time as the configuration drifts.
          • stephenr 9y ago
            > Mac users using a hypervisor? Windows using running Linux in a Virtualbox? Vagrant works natively on Macs and Windows, unlike Docker. There is zero reason to run it inside an already virtualised environment on those machines. > I am talking about rebuilding the Vagrant image every time you change it You know you don't need to destroy the vagrant environment to re-run the provisioning scripts, if something changes.. right? > Sure, once it's written (by someone who has to spend a fair amount of elapsed time doing trial-and-error tweaks) With the minor exception of a few Vagrant specific optimisations (a `vagrant` user with the predefined SSH key & passwordless sudo, for example) during base-box building, literally nothing in a Vagrant provisioning environment needs to be specific to Vagrant. Also - if you're building base-boxes, it's probably worthwhile forking an existing project that targets your Distro/OS of choice and customising from there. > On the other hand, that too can result in people using stale images over time as the configuration drifts. Why? If it's a small change, just set the provisioner to `run: "always"` and it will run on every up. Assuming the changes (i.e. new/updated deps, or config files being copied) are small, it'll be almost instantaneous. From everything you've said, I'm very curious how you use Vagrant (if at all). It isn't intended to be used like Docker, where you package up an entire image completely ready to use with 0 cycles needed to configure anything, and an update means a new image.
• sixhobbits 9y ago
  At the risk of displeasing the Docker crowd, I would say you can get pretty far without them. In general, I see a lot of people learning and using BuzzWord solutions for problems that they don't have. In most cases, you'll have some problem and look for a solution to it. If your problem is spending a lot of time messing around with dependencies and deployments and "but it works on my machine" type issues, then Docker may well be the solution. If you learn a solution and then see what problems it can solve (Hey, everyone is talking about Docker. Let me learn it too), you'll end up frustrated and confused. Of course, it's a balance -- often you can learn about problems that you didn't even know you had by learning about new technology. But so far I see more people erring towards "Let's fix these problems I don't have" than "I'll just keep doing things this slow old way because I don't want to keep up with tech movements"
  • mickeyp 9y ago
    Having worked for for about 18-20 different clients I can count on my left hand the number of places that had turn-key, repeatable dev environments. Repeatable prod environments are usually better but not always. Quite honestly to most lazy developers the idea of repeatable and turn-key environments is anathema to them. "It's time consuming". "It's boring." "It's Somebody Else's Job." It is now my number one way to determine actual seniority and skill level in a developer during interviews. Docker is not the panacea, but it's a game changer for many people as it lowers the barrier to entry for these things. We should embrace containers for what they are -- a very useful tool.
    • stephenr 9y ago
      > turn-key, repeatable dev environments > We should embrace containers for what they are Um.. relatively unrelated to the problem you described? Containers are about isolating one or more processes, memory, network, disk etc from the rest of the host system. This can be used to achieve security benefits, and/or to resolve dependency differences. The problem of repeatable dev environments is solved almost always by a single concept: script it, either using shell scripts, or a configuration tool like Chef, Puppet, etc. In Vagrant, this means one or more provisioning scripts executed in the guest environment (usually a VM, might be LXC or Docker). In Packer, this peans one or more provisioning scripts executed in the guest environment (usually a VM, might be LXC or Docker). In Docker, surprise fucking surprise, it's a script executed in the guest environment.
• sumedh 9y ago
  You can worry about Kubernetes later for now just understand docker basics. Docker really is a game changer. Want to try something in Postgres 9.4, you can do it with just one command, want Rabbit MQ with web stomp enabled, get it with just one command. Setting up Environments with Docker is ridiculously easy, Docker files are pretty intuitive and easy to understand.
• mankash666 9y ago
  Docker & kubernetes are modern Dev ops tools - the former abstracts away the host specific quirks, and the latter allows managing many (docker) containers in production. Should you learn this - it depends. If you plan on building microservices whose devops you'll need to manage, docker is highly recommended. You can get away not learning kubernetes by relying on AWS ECS equivalents, and that's probably what you should do as a beginner wanting to deploy. If your app architecture is event-driven, and can be rest based AWS lambda is a great option where you don't have to learn either. Beware of costs if invoking in the millions, but if your service ever scales to that, you've probably already found a lucrative opportunity that can afford experienced help
  • mickeyp 9y ago
    Sorry, but you don't need to be building microservices to even consider using tools like Docker and Kubernetes. The former (or containers in general) is an excellent way to build repeatable and re-usable environments for development, then your test and CI environment(s), and then finally production, as you -- in a greenfield project, for instance -- crystallise your requirements as you go from the trappings of a blank project to a final one. To say that either tool is aimed at microservices only is very misleading. I will also take some exception to the notion that using Lambda with event sourcing means you don't have to learn how Lambda or, indeed, event sourcing works (pros and cons). OP, your main goal is to ask yourself: a) Can these two tools make my life easier (Docker? Definitely. K8s? Maybe.) b) Do they improve the quality of the work I do so my client/boss is happy?
    • mankash666 9y ago
      Repeatable, reusable environments for development doesn't need docker. And my statement on AWS Lambda is valid - while learning is always a net positive, knowing the innards of lambda's container scheduling isn't necessary for using it. One needn't learn chip design to program a computer, but you probably will write better assembly code of you designed the processor
      • mickeyp 9y ago
• nickjj 9y ago
  I would say it's worth learning Docker. I've been using it since 2014 and it's one of the best software related moves I've made. I wouldn't say I'm a super fan boy of anything, and I typically only use tools when they make my life way better. Docker is one of those tools because it helps me set up development environments for the web applications I develop, as well as help me move those apps to production seamlessly. I'm a freelance dev so I have a lot of projects on my machine, and it's amazing to be able to spin up and shut down each app in seconds and also hand everything over to a client and have them run 1 command to get everything up and running regardless of whether they are running Mac, Windows or Linux. When it comes to production, it's as simple as installing Docker and then running a few commands to have everything up and running with total confidence that it works. That's what Docker can give you in the end with not too much effort. The reason it's a lot better than a VM is how fast and efficient it is. There's no massive disk space overhead and containers start in milliseconds, not minutes. Honestly it's not even comparable to a VM. There's just too many wins that make it an entirely different beast. If you don't want to put in the 50 or 100+ hour grind of learning it on your own, I've assembled a 5 hour premium video course that will teach you how to dockerize your own web apps. You'll walk away fully able to use Docker in the real world. There are node examples too. This course is everything I've learned in the last 3 years of using Docker and is filled with best practices from real world usage and feedback from hundreds of people. You can find that course at https://diveintodocker.com/ https://diveintodocker.com/. If you have any questions let me know. I'd be glad to help. I'm also a Docker Captain (Docker reached out to me to become a trusted content provider) so I'm not just pitching you on buying something (if I didn't fully believe in Docker I wouldn't be spending my time personally using it). I also have plenty of free Docker related material on my blog[0] and Youtube[1]. The first hour of my premium course is available on Youtube, no strings attached. [0]: https://nickjanetakis.com/blog/tag/docker https://nickjanetakis.com/blog/tag/docker [1]: https://www.youtube.com/watch?v=XeSD17YRijk&list=PL-v3vdeWVEsXT-u0JDQZnM90feU3NE3v8 https://www.youtube.com/watch?v=XeSD17YRijk&list=PL-v3vdeWVE...
• machinemob 9y ago
  In the amount of time it took for you to write this question and parse the subsequent opinions, rants and religious arguments, you could have followed a basic Docker tutorial, written a simple Dockerfile and answered the more important questions: Is this useful to me? Can I be more productive with these tools? :)
• twalla 9y ago
  i'd suggest learning the following: 1) how to write dockerfiles [1] 2) docker build, tagging, and push 3) docker run and docker exec 4) docker-compose anything beyond that is probably not worth it unless you're also responsible for your infrastructure. [1] https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#minimize-the-number-of-layers https://docs.docker.com/engine/userguide/eng-image/dockerfil...
• togusa2017 9y ago
  I was running my side project without docker and trust me it was making my life hell due to the difference in production and development environment and also a fear that if I drop this server how the hell am I gonna setup another server with a small amount of downtime. I started moving my side project to docker and in the process learned a lot about it. Now I can't work without a docker . It's not perfect but God it's so much better
• turtlebits 9y ago
  You don't have to, but docker + docker-compose is excellent for getting a development stack setup with extremely little effort (and other tooling you may need) - such as postgres/mysql/redis/mongodb/couchdb/jenkins/etc... You don't need to learn how to build containers. Just the basics of how docker works.
  • turtlebits 9y ago
    Also it allows you to run a bunch of services with little resources and minimal config. I have a OVH $7/mo VPS running - reverse proxy (traefik) - 2 web apps - jenkins - postgres - riemann - thumbor (thumbnailing service)
• indescions_2017 9y ago
  Yes. It's ubiquitous now. It'll be a bit like everyone around you talking about the "Upside Down". And you have no idea because you never watch tv except for Emily Chang. Plus, you can understand it in under 1 hour: https://training.docker.com/introduction-to-docker https://training.docker.com/introduction-to-docker If you are into Node, I'd also get up to speed with Serverless Deployments and Lambda Functions. Buzzwords, yes. But also modern, powerful and game changing. And most importantly, you won't have to worry about any devops internals ;) https://cloud.google.com/functions/ https://cloud.google.com/functions/
• joelbondurant 9y ago
  Docker for Linux != Vagrant/Virtual Box Docker for MacOSX (Unix for idiots) == Vagrant/Virtual Box