Seems that container that serves the website hadn't auto-scaled well ;) (currently it's responding with 502 Bad Gateway)
Based on Google cache results, I suspect that the page's rendered server-side, with React, and the container's really busy doing the same DOM stuff over and over. If owners are reading - I think the easiest trick to try (besides scaling up) would be to tell nginx to cache the index page (with `proxy_cache`), heavily - just don't forget to forcibly drop the cookies on `GET /` requests (for safety). The page from Google's cache looks mostly static, so that should do the trick. It would not know the logged-in state, but at least something would show up.
It's been an hour and we can't still check the site. I would really not trust my production deployment with these guys.
On a side note, Docker Cloud has been offering same thing but they are too slow to deliver docker swarm functionality there. My servers are now running more than a year old version of docker. Does anyone know a great web-ui to manage containers? (I already tried portainer, kubernates-ui - they are either buggy or not intuitive)
Rancher is decent enough for my needs - I mainly setup and manage microservices with load balancing. It's also nifty for the occasional testing of new docker containers without sshing into a dev box
This isn’t very helpful (yet), but I know of one that’s about to be released in beta. If you’d like to be notified when it’s available, shoot me an email via contact info in my profile.
See, that's what happens when "just containerize it to solve scalability" motto is applied. Containers is a technology. Technology is neither positive nor negative. It just is and it comes with upsides and downsides which need to be analyzed and addressed.
This looks like almost what I want for a CI system I am developing, however it is missing several things I would want:
1. Ability to run containers on other platforms (so I can test that my code works on several platforms) like Windows.
2. Per-minute or per-second billing (the testing only takes a few seconds and only occurs a couple of times per day)
Basically, on every commit to specific branches of the code base I want to spawn several docker containers (on someone else's infrastructure) I want to build (./configure && make && make test) the software on Windows/x86, Windows/x86_64, Linux/x86, Linux/x86_64 (and more -- but I'll settle for what I can get...) and then report the results back.
The containers will run for a few seconds and have no dependency on any other infrastructure, so something simple is ideal for me.
> and more -- but I'll settle for what I can get...
Windows (current gen) and Linux are the only platforms that have native official Docker runtimes at this point. There is immature support on some BSDs, nothing on OSX that I know of, and some interesting rumours from the SmartOS/Illumos area.
If you target anything other than Linux/Windows, I'd suggest running your containers in a Linux VM, which is what the official Docker app on e.g. OSX does underneath anyway. In that case, you may not need to consider VM-backed OSes as separate platforms, since according to the code in your container it's still on Linux.
Also, you may already know this, but: if you're building Linux apps (ELF binaries or linux-specific APIs), the docker containers you can run on Windows will still (I think) run in a Linux virtual machine under the covers, so it doesn't really count as a different platform unless you're distributing a Windows application to Windows, and are compiling it for Windows. A bit more info: https://devops.com/native-docker-windows-arrives-containers-...
I know about the lack of supported platforms and it is a real bummer, since it means I have to do something different on those platforms (Android/ARM, Mac OS X/x86_64, FreeBSD/x86_64, AIX/POWER, ...) :-(
The software being built does indeed target Windows APIs natively. It is mature software and supports a lot of platforms.
Unfortunately, the site has been down since I saw it here (4 hours ago) and I've been checking a couple if times an hour.
While my self can handle that, I'm afraid my subconsciousness has already formed an association to the name containerum.com. Very much dreadedly, as I loved that name.
Knew of a couple articles like this, but didn’t have a link handy. Basically as I assumed, at best 50K views in a day. That’s averaging less than one page view a second.
For a blog, that’s a ton of traffic. For a professional business, let alone a hosting provider, that shouldn’t be an issue if they know what they are doing.
Based on Google cache results, I suspect that the page's rendered server-side, with React, and the container's really busy doing the same DOM stuff over and over. If owners are reading - I think the easiest trick to try (besides scaling up) would be to tell nginx to cache the index page (with `proxy_cache`), heavily - just don't forget to forcibly drop the cookies on `GET /` requests (for safety). The page from Google's cache looks mostly static, so that should do the trick. It would not know the logged-in state, but at least something would show up.