I don't want to use Docker. Convince me otherwise

To start of, why would anyone put a PWApplication in a Docker? Why?

Complex, hard-to-setup installations put in a docker to prevent having to do it over and over again might make sense. But a PWA?

A VPS is in itself a container. Why do I need a container within a container?

The usual common reason given is: Docker ensures reproducibility. But haven’t we been reproducing steps using CIs since the beginning of the universe?

Why do I need a CI to deploy a Docker onto a VPS?

Enlighten me.

To shed some more light, here’s how I prefer to deploy my PWAs. My CI script does this

  • CI gets triggered whenever something touches master (using master here, but works similar for staging and dev)
  • git pulls from master branch of repository
  • npm install && npm build --prod
  • If any tests I run them too, and if all checks out and nothing breaks
  • cd /path/to/dist/
  • scp /path/to/server/directory

With the above, no need to reload nginx. The next visits by users will automatically pick up the new files.

Am I missing anything above?

First of all every day convince me, convince me, bro, you don’t need to be convinced, If docker doesn’t work for you then don’t use it.

Secondly, for a very long time, I have been against the use of docker. I still am. but now i understand where docker shines and where it doesn’t. This is the key thing in understanding where to use docker and where not to use docker. For a very long time developers have used docker to solve certain basic problems, they could otherwise have solved by reading documentations. A typical example goes like this,

I didn’t want to do all the Nginx, apache, db configurations, app setup on the ec2 server so I just wrapped the entire app in docker and dumped it there.

Yes, it solves the problem, but it is overkill. You could just have easily deployed this same app on Heroku, google app engine, or AWS elastic beanstalk.

To answer the question of where docker shines. To answer that i will break it up into two use cases which are widely used. For development and for production.

On development, I think that is the most common use case. you don’t want to set up Kong, Postgress, Nginx, along with all the different versions associated with each app and containers that will help you run, build and develop an app so its easy to use docker. Understandably so.

Production is where I think there is a lot of common misuses and abuse of docker. If you are not dealing with scale, using Docker in production is most often the wrong choice. It works but the abstraction layer docker presents to create a new avenue for failure, and when it goes wrong, it is very difficult to fix. When you operate at scale, there is most likely a DevOps engineer more vexed at fixing the issues that come up with docker.
When people talk about reproducibility in docker they are not talking about the reproducibility of the CI steps. They are talking about the ability to reproduce new nodes and containers when workload spikes and also easily turn them down when the workload decreases. This is how you are able to easily automate scaling. All infrastructure service that will help you scale, will accept nothing less than a container with docker being the industry answer. The reason people put their front end apps in docker is that it makes it easy to manage an entire fleet of containers, without having to switch context to zeit of netlify to scale stuff.

When you say you don’t need Nginx, I don’t know if you are deliberately being ignorant. But if you are not, you should know that whatever service you are using to deploy your PWA is using nginx under the hood. Just peeps the access logs.

While docker is good in most cases, under no circumstance should you run your production database in docker.

So to reiterate, using docker in the wrong context is everything wrong with how people use docker.

What I said was “I don’t need to reload Nginx” after replacing contents in the pwa folder. Nginx is so de-facto these days.

A fair point. But at what level of scale is this really necessary? Day one? With 10 users? Or with a hundreds of thousands of users making millions of requests a day? Of course, each and their use cases and needs.

But throwing Docker into the production ring with just 2 users to an application (with the envision that app will grow to 200 billion users in 2 weeks) isn’t realistic and brings on board an unnecessary workload, until there can be a team to handle that should the need be (which in that case, company has grown, revenue has grown to afford more hands on deck)

Yes, thanks for your words so sweet!

Exactly my worry. Some have scaled their apps in their minds and throwing everything they’ve got, meanwhile there are only 2 users lol

You don’t say! I’ve seen production databases running in Docker. Preach!

We seem to be missing the main thing docker solves. Packaging, docker solves this problem so well that everybody just gravitated towards it. It was a problem we had but didn’t know how best to solve it until docker (aka: Dockerfile) showed up.

Running your application in docker is technically no different from running it on the host machine; yes you can use tools (eg: chroot) to restrict the application, which docker does for you automatically and by default. Running in docker also means you don’t have to think about scale, deployment rollback etc; yet, but you can do it anytime.

There are ways around your issue of not restarting nginx (mount the pwa app folder as an external volume) same goes for database. The beauty of having your db in docker is that you can multiple instances with varying versions, you can tryout the new version against your app and revert without breaking a sweat.

If your problem is restarting nginx, then I think you should not be thinking about docker or even nginx because you will/should probably deploy that on a CDN.

Lol. Restarting nginx isn’t a problem ooh. That part I mentioned is in no way saying that’s why i don’t want to use Docker.

What I simply meant was, with such CI pipeline, I wouldn’t even need to restart nginx. That was in no way saying restarting nginx is a problem.

I’m not sure why of the entire message I posted, “restarting nginx” appears to be a recurring theme. Well!

Are you hereby saying or suggesting putting a database in a Docker? @bubu come see ooh. I told you, you’re preaching to not the choir!

And why is that? Docker magically scales itself by spinning up physical servers, and putting itself on all of them in tandem in real time, seamlessly? No dev would have to painstakingly program it to scale, and or test to ensure it works?

Wouldn’t that be the same as the same ol’ deployment orchestration tools out there?

Not everybody, at least not me. I’m not convinced the jump onto Docker. And I’m in no way saying Docker isn’t useful.

What I’m saying is, almost everybody I see using Docker, is abusing Docker, as in, using it for what it’s not intended for. And what does that mean?

I could buy a 60 foot trailer, drive it to work each day, go shop in town for 2 fingers of plantain on the weekends, and go on vacation to Kumasi with it. But is that what a trailer was “intended” for? It can carry 1 cement bag alright. But that’s not what it was meant to solve.

You talk of packaging as if it’s been a problem. If it’s a django application, virtual envs solved it seamlessly, for example. Nginx virtual host solves running multiple services in the same Container - the VPS.

I can list a million other well-tailored solutions for every scenario. Yet, of all those tailored solutions, then they bundle all of those solutions and put in in yet another Docker.

I hope people would stop using these containers and kubernetes all in the name of that’s what other multi -million -billion dollar companies use it, think by using what the others use, they might end up growing to be like them.

Except it doesn’t work like that.

The issue of putting the db in docker has more to do with the data that the software itself, I don’t think it makes sense to put your data inside the docker volume but running the software with your data folder mounted as a volume.

Yes virtual envs solves it for django…but the world is not all about django now is it? Docker makes a single concern disappear, the guy building the app, creates a deploy package and boom, the app is always deployable. Btw, what if you are running an older version of django that needs an older version of python or older version of postgres (but the guy who built it left the company.)? How do you communicate that to the person deploying your app? README?

Docker won’t have the kind of adaption it had if it just about another big company. Look docker inc wasn’t big when docker came out.

That is a non-argument.

Yes. Because the person deploying it will not have to figure out whether to install JRE or JDK or Tomcat 7 or 6. All that is handled with a single docker build.

And that is where docker shines.

Yes, definately people shouldn’t do because somebody else is doing…they should judge on the merit and general usefulness (I am looking at you Kubernetes) of each platform. But hey, I know a lot of apps that a simple php and/or laravel app will suffice but are built with React/Vue/etc.