Host Your Blog on DigitalOcean with Docker, Nginx and Let’s Encrypt | Hacker News Reader

Host Your Blog on DigitalOcean with Docker, Nginx and Let’s Encrypt

archij.com

> volumes: - /var/run/docker.sock:/var/run/docker.sock:ro

Please for the love of all that is holy, do not ever do this! Giving access to the host's Docker socket is equivalent to giving a container unrestricted root access to your host. Mounting the socket read-only doesn't protect you in any way either, because you can still connect to and write to the socket! Seriously, try it:

    % touch /tmp/docker.sock
    % mount --bind -o ro /var/run/docker.sock /tmp/docker.sock # this is -v /var/run/docker.sock:/foo:ro
    % docker -H unix:///tmp/docker.sock run --privileged -v /:/host -it ubuntu bash
    # # I couldn't write to it, but I can connect and write to the connection...
    # cat /host/etc/shadow # whoops!

(The full container escape is left as an exercise for the reader. It's pretty trivial though.)

To be fair, there are unix-like DAC controls that do restrict this somewhat but given that most people run containers as root or they don't use user namespaces this is still an issue.

Please stop doing this, please stop telling people to do this, and please stop making images that access docker.sock. I understand that this is something that a lot of people do, so it's obviously not exclusively the fault of the author for doing what the majority of people appear to be doing, but I think that this deserves to be said much stronger than it was in the past (people still expose Docker over the internet -- which is literally a free root-level RCE for anyone who figures out you're hosting it).

And yes, AuthZ plugins exist but nobody really uses them as far as I'm aware -- and personally (as someone who maintains container runtimes and other low-level container tools) I would not feel confident in depending on any AuthZ plugin's profile to protect against a container escape where you give unprivileged users access to /var/run/docker.sock. Even if I were to write one.

This is where it comes from and that's probably why it isn't explained in the post: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...

It seems like if the author(s) of docker-letsencrypt-nginx-proxy-companion had assumed something like docker compose or kubernetes that neatly handles sharing volumes between containers, they probably wouldn't have made the mistake of giving a docker container access to docker for such a trivial use.

I disagree that there's never a good reason to do this though. A docker control panel, or a CI or FaaS that spawns docker containers, can be a good reason to do this. https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-d...

BTW there's no escaping the container when you're doing this intentionally.

> I disagree that there's never a good reason to do this though.

The number of cases where it is an acceptable idea to do this (compared to the number of cases where people do this because they read it on a random blog post) is so small that it is statistically insignificant. In my view, it is much better to tell people to never do something which is very rarely useful. People who know better would know when to ignore that warning (which I would hope would be the sort of people who would write a CI or FaaS), while those who don't know better likely wouldn't use it in a way that is "safe".

The blog post you link to is quite old (this was at a time when most users were well aware of what docker.sock did -- so much so that vulnerabilities I helped find in Docker from that time were not regarded vulnerabilities because they required docker.sock access!). I agree with Jerome's point which was to dissuade usage of Docker-in-Docker. His point was not that bind-mounting the docker.sock is generally an okay thing to do -- and as I said I think that we should be far more vocal about how dangerous this is (because people don't listen otherwise -- as has been shown by the fact that there are still plenty of users that have Docker listening on a TCP socket without client certificates).

> BTW there's no escaping the container when you're doing this intentionally.

I don't know what you mean by this -- if you bind-mount the docker.sock inside a container that container can trivially get root access on the host (AuthZ plugins can make it harder but as I said they are rarely used and cannot protect you from sufficiently clever attackers). My demo with 'mount --bind' was just to show how it worked, the same thing happens with '-v' (which is just a bind-mount under the hood).

Now, if you argue that the code in the container is always something you trust (which I think is a questionable assumption as it assumes that your code is not exploitable) then sure -- if all the code on your machine is safe you have no worries. But then the obvious question arises -- why do you need the isolation properties of containers in the first place? Why not just run in a chroot?

why do you need the isolation properties of containers in the first place? Why not just run in a chroot?

Docker containers are about more than isolation, they're also packaging. In my case, I already have a docker-compose.yaml with five services; adding another program as a chroot instead of a sixth service would significantly increase the installation complexity.

I do agree with you that mounting the Docker socket should never be recommended on a tutorial.

Right, there is a tooling argument. My point was that you can get most of the packaging with just chroot -- images are just tar archives at the end of the day.

But I might be biased given that while I've worked on both runtimes and image tools, runtimes have a lot more interesting problems so I tend to focus more on them when discussing the benefits of containers. :P

What is Faas here? Firewall as a service? Can you say why mounting the Docker would be intuitive there? Thanks.

Functions as a Service. It's useful for any service that uses the Docker API that you want to run in a small single-host environment. https://github.com/openfaas/faas/blob/master/docker-compose....

Ah right - "serverless." I hadn't yet heard that acronym. Thanks.

It's condescending to tell people to never ever ever do something that's infrequently useful. I tend not to trust people who take that manipulative approach. And your experience doesn't represent the whole of how Docker is used. You especially seem to be irked by using Docker partly for convenience within a single host, but also to isolate a container that contains code from many different sources (npm packages) that are more frequently updated (the node.js/ghost container doesn't have access to the docker socket). This is mixing different uses of Docker.

On the second point, I mean that to call it escaping the container is incorrect. If they are given access to the docker socket intentionally, the expectation that it wouldn't be able to do anything with the server outside the container is gone.

> It's condescending to tell people to never ever ever do something that's infrequently useful. I tend not to trust people who take that manipulative approach.

We'll have to agree to disagree on this one. I originally wrote a longer explanation of how you need to distill an argument in order for non-domain-experts to get the gist, but if you think I'm manipulative there's not much to be said.

There is an argument to be made that any misconfiguration has a specific niche usecase (otherwise it wouldn't be configurable) -- so telling people to not do something is always "manipulative". But we have security best practices, and we tell people not to misconfigure things. There is a time when you should use 'curl --insecure' but we tell people not to use it because those who know when to use it also know when it is safe to use it.

> And your experience doesn't represent the whole of how Docker is used. [...] This is mixing different uses of Docker.

But running an node package as an unprivileged user on the host doesn't give it free root access on your machine. 'docker run -v /var/run/docker.sock:/var/run/docker.sock:ro' does, and so while you might argue that isolation is not a property everyone is interested in (which might very well be true[+]), the net result is a setup that is more insecure than the equivalent host-side setup (nobody runs node packages as root on the host in production I would hope).

> I mean that to call it escaping the container is incorrect.

It's not though. You are in a container and then you use a misconfiguration to break out of it. Just because it's trivial -- and it is very trivial -- doesn't make it not a container escape. You would use the exact same techniques to break out of a container that had a "real" container escape vulnerability -- namely `nsenter --mount=/host/proc/1/ns/mnt` or similar.

If someone misconfigured sudo on some ISO image to permit everyone to have root access, that would still be a privilege escalation vulnerability even though it caused by an intentional misconfiguration. It might not be as neat as other vulnerabilities, but it is still a vulnerability.

> If they are given access to the docker socket intentionally, the expectation that it wouldn't be able to do anything with the server outside the container is gone.

You say that from a position where you know that docker.sock access is equivalent to root host access. Many people are not aware of this, and are not told this when they are told to bind-mount docker.sock into containers that have potentially insecure software running in them. If everyone knew that this was the case, you might be right in arguing that you've already given up container (or even user) isolation at that point -- but it's not clear enough in my opinion.

[+]: Though I don't see why you should undermine it needlessly -- given that it is the most expensive and complicated parts of setting up a container. Images are effectively just tar archives.

Socket exposure can be avoided by running jwilder's nginx and docker-gen containers separately as explained in his repo (you still bind to tthe docker socket but on a separate unexposed local container): https://github.com/jwilder/nginx-proxy/blob/master/README.md...

I was a bit worried too about exposing the docker socket, even to a well trusted image and even if it seems it'a a widely adopted practice for such automatic configurations.

Fortunately ducaale suggested https://hub.docker.com/r/steveltn/https-portal/.

I adapted the site and will publish a follow-up about using this image for nginx - let's encrypt configuration.

Here the follow-up:

https://www.archij.com/improving-the-blog-security/

> people still expose Docker over the internet -- which is literally a free root-level RCE for anyone who figures out you're hosting it

By default, docker-machine (which sets up internet-accessible docker instances) uses TLS client certificates, so no, this does not give a "free root-level RCE". This is just spreading FUD. (This does not detract from the parent's point that "access to docker.sock" == "root on the host". That part is true.)

I was not referring to docker-machine here, I'm not sure why you think I was referring to it (I didn't even mention it). I was talking about people who do `dockerd -H tcp://:8080` and ignore the warning that tells them this is insecure. This is not a strawman, there were blog posts in the past few months where they mentioned in passing that their firewall was misconfigured and allowed unauthenticated access to their Docker hosts[1].

I didn't mention TLS certificates with -H tcp:// because it wasn't really related to the main point I was making -- yes you can configure it to be secure but again security is not the default. I felt so strongly about this I pushed for having a required flag to allow insecure TCP access[2]. I am more than aware this can be done safely, it just isn't done safely often enough that you see this type of misconfiguration in blog posts.

[1]: https://kromtech.com/blog/security-center/cryptojacking-inva... [2]: https://github.com/moby/moby/pull/37299

Security with client certificates is the default using the vendor-supplied tooling for bringing up remote docket hosts, docker-machine. This is why I brought it up. It’s not some 3p whatever, this is the vendor’s tooling and it is not insecure by default.

I I’m not going to tell people not to do this, but in my opinion this is massive overkill for a simple blog. Why use docker when you can just run nginx on the host with certbot for LetsEncrypt.

I guess docker gives you some flexibility for rollover and load balancing, but a single droplet will handle huge amounts of traffic for static sites.

In some sense everything is massive overkill for a "simple blog". You should just pay for medium/wordpress/ghost or use a static site hosted on github pages.

I personally fell for these posts a while back and regretted spending time on it. They don't tell you about the crazy amount of sysadmin skills that you need to get it up and running:

Do you need to worry about updates/security patches? How do you configure firewalls? How do you configure ssh settings? How would you even audit unauthorized logins? Where are logs stored? Are they rotated? Are they backed up? Are there backups? How do you restore from backups? How do you configure nginx? How do you configure certbot? How do you check if cron is running correctly? Do you ever look at access/error logs? How do you keep services running upon restart? How do you get notified of problems? How do you monitor uptime?

Each individual question will take minutes to hours to research and will open up new rabbit holes.

That's why I think these blogs/projects are useful. Or should people learn all this stuff first time they run a real app in production?

Most bloggers aren't ever going to "run a real app in production."

Most {net,dev,sec}ops engineers aren't writing blogs.

> Most {net,dev,sec}ops engineers aren't writing blogs.

Unfortunately, in my experience this is true. It's not for lack of motivation or desire, it's because my day job is stressful and tiring. The last thing I want to do when I come home in the evening is to spend my valuable personal time writing a blog about what I did at work. I would rather spend time with my family, or do something like that.

Of course, I could try to schedule time during work hours to write a blog on the company website by talking with my manager about it. Unless this advances any strategic or political agenda, it's unlikely to happen.

You could write about non work stuff that interests you, and only do it on occasional instances where you feel like writing, and pay someone like wordpress.com a pittance to handle the tech. This is what most web logs were like in the beginning.

I write a post on my blog about my interests once every month or two, and maybe crosspost it to Facebook, but I like that I get to write down my thoughts on a site I own.

If you don't get much enjoyment out of writing period though, not much reason to blog.

I personally blog about things I've found while working that have been a pain or a "oh hey, cool!" that I've not seen documented anywhere easily, so I write about them under the term "blogumentation" (blogging as a form of self-documenting) https://www.jvt.me/posts/tags/blogumentation/, reasoning found in https://www.jvt.me/posts/2017/06/25/blogumentation/

I've found it useful for myself and colleagues, but also it's really awesome seeing hits from Google and other mediums where people are obviously finding it organically and sharing around through various means. Helping others find new / better ways to do things is really awesome

I suspect most who do also don't feel like dealing with all their day job BS just to run a blog. Not when they can just use a hosted platform, or throw things up on S3 or something.

They may not. But most of them get asked about Docker and all kind of "shiny new keywords" in interviews right?

> Each individual question will take minutes to hours to research and will open up new rabbit holes.

That's all part of the fun for DIY projects like this. Paying someone else to handle it for you isn't really part of the hacker ethos.

Yes, but not if your aim is "to run a blog".

I set up DO to host a half dozen websites with a standard LAMP, NginX reverse proxy, and such. Then set up email with horde, spam filtering etc., then realised that managing all of that without breaking anything was going to be a pain in the arse. The web side is relatively straight forward, the email side was really fragile.

So I switched to a shared hosting account for about the same monetary cost.

Generally I enjoy the admin, but I'd be needing a duplicate test system to trial optimisations; a part-time hobby is then looking like a full-time job.

Yes, this is the reason 'ops' exists and developers shouldn't just run wild in the organization. DevOps is 'we made our ops people become developers' or worse, 'We let out developers use docker!'

All kidding aside, it is a lot of work, and you have two options: 1) learn these things yourself 2) pay someone else to do them for you.

I'm a fan of #1, as they are valuable skill sets that let you be on the receiving end of option #2.

Is it ever the other way around. Admin looking to get into devops?

Sure, lots of 'devops' people come from the ops side, probably more than strictly developers.

I'm not a fan of the 'devops' term, generally.

If you have some time and curiosity as all these things version become an interesting list of things to learn.

There's tons of value in doing things yourself

There are many reasons why you would want to use Docker but for me the biggest one is that the entire configuration, installation, and deployment is all self-contained in that docker-compose file. The rollover and load balancing features are also nice if you need to scale out but even on a single server there is a solid case to be made to use Docker. The alternative you've presented is that you'd need to install and configure Nginx, then install and configure LetsEncrypt, then install and configure Ghost. And then you'd need to make sure you documented all the steps you've performed so that you can do it again if needed in the future. The docker-compose file aligns to the "infrastructure as code" methodology and while there are many other tools that could achieve the same thing (Terraform, Ansible, Salt, etc) using docker-compose in this scenario seems to make sense.

Installing and configuring Caddy to serve a static site over HTTPS is dead easy, and probably less work than setting up Docker.

Caddy has built-in support for Let’s Encrypt.

I use the dns module which required a little bit of extra work to enable because it’s not included by default but other than that it’s very simple like I said.

Here is the config file for one of my sites:

    www.crusaders.pw {
        root /var/www/pw.crusaders.www/
    
        expires {
            match .htm$ 4h
            match /assets/.* 1y
        }

        tls {
            dns cloudflare
        }
    }
    
    crusaders.pw {
        redir https://www.crusaders.pw{uri}

        tls {
            dns cloudflare
        }
    }

Then just stick the config file in a git repo.

> There are many reasons why you would want to use Docker but for me the biggest one is that the entire configuration, installation, and deployment is all self-contained in that docker-compose file.

Until you write your first blog post or get a single comment. Then you need backups like everyone else who runs their own shit.

The fact that everything is done with a single compose file is the reason I set it up like this (mostly because it was a good learning opportunity). I'm still trying to find a way around the necessity to expose the docker socket to configure the proxy though.

> Why use...

This is usually the most important question to ask about a tool for a project.

However, it is reasonable for the answer to be "because I"ve heard that this tool is useful, and I want to better understand how it is shaped and what things are hard/easy to do with it"

Which is cool when it's your own personal blog and all, but when it happens in a production environment and it's an unnecessary component, and you're the only person working on it, and you omit to document how you're using it before leaving for another job ...

I believe this is referred to as "resume driven development".

S3 with a static blog generator seems sufficient at this point and will likely cost pennies per month.

Agreed. I do this and I pay around 5 cents a month. Can't imagine wanting to run Docker for a simple static blog.

It might be a good simple project for those not familiar with Docker and web server/nginx configuration. But other than that, I agree with you. Seems like a lot of overhead.

Well, if you are complaining about "overkill", why even run a server? It's a blog, it can be static. Serve from S3, Github pages or what have you.

I use it on my own server, a dedicated quad-core machine with 64 GB RAM (hetzner.de). Mainly because I host a multitude of different websites that require different technologies: PHP, Rails, Node, Go and Python. Setting everything up with Docker makes management a breeze and I can easily relocate and backup the entire setup to a different server.

I backup everything daily to my Synology at home.

Now this makes sense to me, but depending on how much you're paying in the case of DigitalOcean you could just spin up different droplets.

For anyone interested, here is a stab at a flask, nginx, gunicorn, and Let's Encrypt setup on a digital ocean server. Disclaimer: I am a rank novice when it comes to web development and would appreciate any feedback.

https://github.com/cirgue/flask_template

Not sure about that, I find it odd to run docker on DigitalOcean. I gave up trying to write my own blog engine for now and decided to use wordpress on a shared host that costs me $5 a year. Way easier and less overhead. No docker, no monthly payments, just a blog.

Why use any of that when every cloud provider incl Digital Ocean has a click-to-deploy WordPress app and you can just use Cloudflare DNS records for DDoS protection/speed/SSL all in one with no configuration required?

I'm a huge advocate of using Docker but a static blog is one of the use cases where I don't bother using Docker. It's mainly because development and production are very different in that case.

It's a good learnin' experience. but ideally for this a simple netlify/static site generator would be the bizzy.

Why I use Docker for everything? saves me from dependency hell, chasing down the required libraries. Plus, some more complex stacks, which normally would take like half day to install now take just one "docker run" command (or "docker-compose up"). That's how I installed Nextcloud, Gitlab, etc.

I think that Docker is a great time saver for those who want just to play with a new piece of software, and don't have the time to learn all the details of some arcane install procedure.

> I think that Docker is a great time saver for those who want just to play with a new piece of software, and don't have the time to learn all the details of some arcane install procedure.

That's true, but if you do that in production you're running untrusted code that could do pretty much anything.

If you don't have your own Docker registry full of containers you either made yourself or have audited yourself, you might as well let anyone in the world run their code on your servers.

And if you do have your own registry, it's a lot of work and it involves chasing down libraries and working with arcane install procedures. You can't really trust the public base images unless you fork them and audit them yourself, or just create your own.

At some point you need to take responsibility for your own stack. Docker fine for messing around on your laptop but the real work starts when you need to get past that.

But if you are not reviewing every other piece of code that you run without Docker it’s not much different from running it in Docker without reviewing the base image / images pulled in as dependencies.

Indeed, for more and more people Docker is just the standard packaging solution. It's like saying "why use packages? You can just download the source and dependencies, then compile it manually".

Having been down that path, don't do this to yourself. Just use a static site generator and Netlify, and save yourself countless hours of work and headache.

Yeah there really isn't any reason to do this other than wanting to specifically use these technologies.. Way easier with generators. Also you can save a lot of money by hosting it cheap instead of DigitalOcean.

For blogs that are “small” and/or expect low traffic, if someone doesn’t want to use free services, my recommendation would be a static site generator that pushes content to a site on Nearly Free Speech (nearlyfreespeech.net). It has a very simple way to create (and continuously renew) a letsencrypt TLS certificate. The cost would be USD 1.5 a month (or a bit higher than that) for what’s classified as a “production site” there.

One drawback with NFSN is that it requires people to be somewhat tech savvy and know how to manage sites, probably use ssh, etc. If you’re someone who can use S3 or this solution, then you’ll find NFSN easier and cheaper for this use case.

I love NFSN. I wrote a detailed review a while back: https://winningwp.com/nearlyfreespeech-web-hosting-review/

(Not much has changed since then, and I'm still a happy customer.)

Nice writeup. Thanks for that!

Absolutely do not do this.

host your blog on https://pages.github.com or https://www.netlify.com

shout-out to gitlab pages, I use it and love it.

Awesome, thank you for your kind support. We really appreciate that.

I think gitlab pages is a great way to introduce people to the philosophy of gitlab.

I could imagine a pipeline setup in the future (with the help of web IDE) that will allow authors to write and commit new articles, for editors to edit them and sign them off to the publisher, and the publisher to publish articles to a static site without leaving the browser. Thoughts?

To everyone saying "use a static site", this deploys Ghost which is a blogging application that provides an admin interface to create and edit posts.

Yes, you can use something like Netlify CMS or Contentful with a static site to get an admin interface, but those would require additional setup or payment beyond github pages or a netlify account.

It'd be nice to see a follow-up post on how to keep this setup up-to-date with the latest security fixes without service disruption.

  ~$ docker-compose pull
  ~$ docker-compose up -d --build

The compose files are already using latest, so this pulls the latest images, rebuilds images with any new code, and restarts the services.

assuming jwilder publishes updated images..

Oh, for upstream/base? If a Docker Hub image was set up with automated builds, it would automatically rebuild the image once its base was rebuilt. It looks like nginx was set up this way, but nginx-proxy was not. So you have to rebuild nginx-proxy manually.

  ~$ git clone https://github.com/jwilder/nginx-proxy
  ~$ cd nginx-proxy
  ~$ docker build -f Dockerfile.alpine -t my-own-tag-name/nginx-proxy:alpine .
  ~$ cd ..
  ~$ sed -i -e 's/image: jwilder\/nginx-proxy.*/image: my-own-tag-name\/nginx-proxy:alpine/' docker-compose.yaml

Alternately, you could fork the nginx-proxy repo, build it, push it to your own Docker Hub account, and add the Repository Links[1] back to nginx. Then you could use TravisCI to automatically pull in and rebuild changes from the parent nginx-proxy. This way you get automated builds when base is updated, and when nginx-proxy is updated.

[1] https://docs.docker.com/docker-hub/builds/#repository-links

Yes, it is entirely possible to do the right thing.

The trouble is 9 times out of 10, the only place you find it documented is in some random forum post where cargo-cult silliness gets critiqued, rather than by the folks publishing these how-tos.

These aren't even how-tos, they're clickblogs. If you'd like to contribute to actual HOWTOs for this kind of stuff, I'm building a wiki...

link to the wiki for a noob?

I try... it’s tough to keep up with everything, but I do try to merge nginx/security PRs promptly.

If you're hit by a bus tomorrow, at what point do folks know to migrate off your never-to-be-maintained-again image?

Don't get me wrong -- I'm not trying to discourage you from sharing configs and artifacts that work for you. They're valuable information to publish.

I just get terrified when I see folks regularly deploying images maintained by individuals rather than organizations.

Sure, that’s a valid concern. I think there are some other aspects of projects to consider than only the the org vs individual distinction though.

For example, I first wrote about nginx-proxy and docker-gen 4 years ago (http://jasonwilder.com/blog/2014/03/25/automated-nginx-rever...). Since then, both projects have gone through continued releases with bug fixes, updates and new features. Between the two projects, there are about 110 different contributors and I am no longer the top contributor on one of them.

The projects are MIT licensed and free to be forked or maintained independently if neeeded.

There’s a large community of users that write blogs, help with issues, and even create derivative works inspired or derived from the project.

Finally, I’d add that a lot of orgs behind projects are really just an individual that wants to make a useful closed source project open for others. The org or company name attached doesn’t necessarily mean a company is going to support it any better than a dedicated individual or community that cares about it.

Is this the proper way to share file sockets?

Also, why Docker and not just an Ansible script?

update:

Found this...

https://github.com/jkap/ansible-ghost-letsencrypt

Why not Terraform? Why not Puppet? Why not X? Pick your poison. But it does seem simpler to not have to learn Ansible if you're already using Docker.

The example you give has 6 config files.... the linked article uses 1 config file. shrug

> Why not X?

Since when does X[1] support system-wide configuration/deployment?

1. https://en.wikipedia.org/wiki/X_Window_System

So if you know Docker, you shouldn't know how to do things without a container?

Nobody said that.

But yea, when using Docker already, why not? It's quick and easy compared to all the alternatives.

It's not easier than pushing a static site up to a CDN. Let someone else do the work until you're using actual compute.

EDIT: Others are already expressing my point, that this is overkill for a blog.

That's entirely different than what this thread is about. Many different ways to build and host a site, although many would find it simpler to just run Ghost or Wordpress and have the GUI for their posts.

You can still use a CDN in front of a very tiny VM. Some new blog engines even support running on serverless/FaaS platforms for every easier deployments, and once FaaS evolves into just running Docker containers then the circle will complete and we'll have the best of everything.

Why add an additional layer of abstraction?

Really, you don't even need Ansible.

Just ssh into the box, apt install nginx, run the Let's Encrypt script and install Ghost.

The docker-machine command creates the droplet for you, and then docker-compose runs everything for you. It's two commands and one config. It's repeatable, automated, fast, simple, and complete.

But, sure, you could do it in a more complicated way, or a more manual and time consuming way that isn't documented or automated. I think that's called the "job security" method.

How many static blogs are you deploying?

Shouldn't we also be using k8s to orchestrate all the blogs?

Yes, k8s would make it even easier, if you had access to a hosted k8s cluster. But that isn't what DigitalOcean provides.

It does now: https://www.digitalocean.com/products/kubernetes/

It's less about "why would I use ansible?" and more about "why wouldn't I use docker?"

That heavily depends on if this is a "learn new tech" thing or not. Some people view setting up a blog as a challenge to solve, and some people just want a blog up and running so they can write. And if this does it in a simple to follow guide that is reliable, the tech behind it doesn't really matter.

Because the docker-compose is perfectly fine here?

This is NOT meant to be incendiary. I'm trying to learn. Why not use Netlify instead? It seems to have everything you need from a static site host and has a comprehensive, well-documented toolchain. Seriously, what am I missing? Would DO be better under peak loads or something?

No, it's just that Netlify is proprietary and only works for static sites. The method in this article is more general.

For this use-case Netlify is the better option.

Thanks much. I really was trying to learn, downvotes to the contrary.

While this is pretty cool, it's also not all that much of an effort to setup https using certbot and have it automatically configure nginx: https://smalldata.tech/blog/2015/12/29/nginx-nodejs-and-http...

Setting up the renew job is also a very simple cron job.

Moreover, something that one forgets is that once you have your posts, comments and any sort of data, you need to have backups and other sysadminy stuff.

Personally, I enjoyed learning about this while setting up my blog :)

Perhaps a bit off-topic, but if you run a lighter blog and specifically want to do it on a machine you control the I can recommend using the nginx:alpine docker image to host your site. All you need to build it is a COPY command:

   COPY ./my_static_files /usr/share/nginx/html

This alone wont get you HTTPS, but I wouldn't be surprised if you can get that working with little effort using docker volumes and certbot

Once, I worked on a Rails app that was setup in a docker compose environment. I won't talk about prod, but was very surprised to see how much more complex it made developing locally, having to deal with docker instances and such, compared to just run `rails s` if we weren't using Docker.

Was the app setup improperly, or is that expected that using Docker will make local development more complex?

It's a mixed bag. Some of it was probably improper setup. With mounts and docker exec and such it's easy to go into the container and rails s or rails console and do what you need to do. But you have to deal with user permissions if your app creates files and some other things but you can just use a docker container as a very lightweight VM.

On the other side you have to track down and figure out how to install or build whatever obscure old Ruby version they're using and dirty your machine installing and running services to support the app. All of which is also painful.

I do client work and I'd rather not dirty my machine installing old or random software to work on a project. So having portable local environments works well for me. But they do take some thought to set up and people often don't take enough care in either case to document the procedure for getting things set up to work on it.

Like, why?

Am I being too cheeky if I point out that setting up a droplet with a WordPress blog on DigitalOcean takes three minutes? :)

(They have a premade image for it)

The most efficient host-your-own-blog I've ever seen is just static blog generation & S3. I don't do it myself (ironically, I run tiny kubernetes cluster and in the past had a systemd-managed docker+ngin+LE setup before that) but it doesn't get much simpler than uploading a folder to S3 that's being served by amazon as a website.

More people should know about Caddy. A webserver with built-in HTTPS. We've been using it in production and the experience has been great so far: https://caddyserver.com/

Using caddy for anything that might be commercial,by compiling, seems like a huge pain:

https://www.digitalocean.com/community/tutorials/how-to-host...

The Caddy license page states that:

"If your company uses official Caddy binaries internally, in production, or distributes Caddy, a commercial license is required."

So if you are not using the official binaries (for example a community-provided Caddy Docker image) a commercial license is not required.

or you can just use https://github.com/SteveLTN/https-portal for ssl termination

How about not using any of that and instead using one of the hundred static site generators on GitHub and github.io hosting?

it's twice as expensive? $120 a year vs $60? (unless you make your content open source in which case github is free)

Gitlab also provides hosting and free private repos.

I want FTP back!

SFTP?

I've been using Netlify for a while with Hugo as site generator. It's free with HTTPS and CDN support.

Why do you guys love complexing so much? Why not use one click wp instance from DO images?

Because it's fun

Hugo + Netlify is simpler and faster. Just saying.

GitHub pages with HTTPS support is easier :P

Would this work OK in 512mb at, say, Vultr?

As long as you have some swap configured you’ll probably be fine.

DO requests that you don't use swap as it degrades their SSDs.

https://www.digitalocean.com/community/tutorials/how-to-add-...

Alternately, generate static HTML, run a bare web server and use about 16MB of RAM.

Spot on! I pity the resources we waste. It seems people have forgotten to respect the fundamentals of computing.

Why even bother running a web server? Just use S3 with cloudfront.

It looks like this would work, but you would have to use www.myblog.com instead of myblog.com since you have to use a CNAME to use cloudfront. Maybe using cloudflare's CNAME flattening?

Unless you host your domain servers on Route53, in which case you can configure an alias record at the apex.

OpenBSD with HTTPD or Hiawatha is SMALL.

Premature optimization something something...and honestly this isn't even optimization, just some extra complexity.

Dockers cool for doing dev stuff on your laptop, or for scaling out with something like kubernetes. This is just silly!

I really miss the days when plain text files were used on a simple apache server linked with simple html pages. We've gone from concentrating on content to concentrating on the visuals, first.

use medium

This was already proposed and shot down for various reasons: https://news.ycombinator.com/item?id=17983366

I'm just curious - why? Forgive me if I am missing the obvious advantage over a blogging platform like medium.

Medium's reading experience is pretty bad with all the annoying popups showing up all over the place. Also with Ghost you can easily export your data and move it across different ghost installations, you can customize the look and feel of the blog, you can use your own custom domain without paying medium extra for that, etc.

For anyone that wants to move from Medium to Ghost easily, I made this thing to do that: https://github.com/ageitgey/medium_to_ghost

Ghost uses markdown, right? So does this tool export my medium blogs as markdown files, with links to the image files already embedded?

If so, I will be forever indebted xD

Ghost 2.0 uses Mobiledoc format now. But you could get Markdown + Images out of this with a little hacking and passing the output to https://github.com/yuloh/mobiledoc-markdown-renderer

Apparently it uses a format called Mobiledoc¹, not Markdown.

¹ https://github.com/bustle/mobiledoc-kit/blob/master/MOBILEDO...

Medium has tracking and social media integration. And you don't have any real control over the platform.

(Also, the sticky headers are so damn annoying!)

What do you mean by sticky headers?

The industry term is "dickbar", coined by John Gruber about persistent toolbars:

https://daringfireball.net/linked/2011/03/06/dickbar

The big header on the top of the screen that doesn't go away when you scroll down. It takes up a ton of vertical space on a phone. About a third of the screen in landscape!

The stupid app thing on mobile view never goes away now

Ahh, thank you I haven't heard this term yet.

Not giving your content to someone else. Not obeying their rules. Having control over the domain name (Medium doesn't support adding custom domains anymore).

medium is horrible if you want comments since it requires people to have medium account

also medium isn't nearly as customizable as your own blog. Can you do this on medium?

http://cabbibo.com/

medium doesn't allow you to bring your own domain, and that's fairly crucial. Both for longevity (can always point a domain at a new host, even if it's just a bunch of static files somewhere, if the old host goes away or becomes bad in some way) and identity: proper name instead of "yet another medium blog", which isn't exactly a signal of quality.

Still, there's tons of hosting options where that's not an issue. Running a VPS can be interesting and fun, but if you just want to host a simple site there's easier options that work just as well.

This does not belong on HN at all. 1) It is not novel or interesting and 2) it is made worse through being self-promotion. Do not make posts like this.

Edited to add: But to scratch the stupid itch I tried hard not to scratch and respond to the other people here, I do this with my own personal blog and it's totally fine. All of my self-hosted software is containerized behind an HTTP reverse proxy. I can do it any number of ways but "Rely on <external third-party service>" seems like a terrible idea to me. And there is no reason whatsoever for all the posts in this thread naysaying this particular way of doing it, any more than there's any particular reason to naysay the suggested alternatives. Do whatever you want. Learn something. Improve your skillset.

Read the HN rules. People are allowed to submit their own content. By the way, your username appears to promote a disgusting slang term. How is that any better?

There were two whole qualifiers in my statement, half of which you ignored. Self-promotion is obviously okay. However self-promotion of bland, boring posts that regurgitate nearly useless information which has been posted hundreds of times... Edit: Oh, I see that you have a long history of twisting the words of others and personally attacking those you disagree with, so we're done here. You have a nice evening.

Reply on news.ycombinator.com