creztoe

That's how I understand it. Basically you have a machine hosted somewhere with a dedicated IP so you can access all remote machines from anywhere at any time, as long as they are connected to it via reverse proxy.

Do not pass sensitive data to docker build via --build-arg. When you access this with "ARG" you will log the information in the docker history, visible to all. Use "--secret" or use the ARG in an intermediate build stage which doesn't have it's history preserved, then copy any necessary files form the intermediate image to your file image manually.

A perfect example of this would be passing your NPM_TOKEN to install company scope packages.

This kind of confuses me a bit. Why would you want to turn Pub/Sub into a queue?

How badly does this affect message acknowledgment and retries? I assume just a huge hit to latency. This seems like a horrible idea for anyone expecting to use multiple subscribers or expecting to chunk multiple messages per request.

Services relying on Pub/Sub should be idempotent anyway. If you need to work around that for some reason, you are better off dumping messages from your subscriber into RabbotMQ or Redis for processing and use a Subscriber/Scheduler/Worker pattern.

Maybe it's just me, but I didn't get that from rozab's comment at all. I figured the point was something like, "Why is this project unique? Maybe the time would have been better spent contributing to an established project that has already accomplished these basic features." Which seems like an honest question.

This seems like it's just a click-baity ad for their productivity analysis tools. I struggle to find a single thing of value in this post.

I'm lazy. I've found a gitlab wiki sufficient for my basic needs. 1. Version control 2. Easily editable from terminal (markdown) 3. Easily viewed via browser (either on gitlab or self hosted gollum instance) 4. Supports some HTML, such as `details` and `summary` for drop down visibility. 5. Supports `[[_TOC_]]` to add a table of contents (works well with in `details` at the top of every page) 6. Supports nested directories for the sidebar navigation on gitlab (github forces a single layer)

Yeah, I was referring to the certbot warning of "logging" the IP publicly. But I guess that policy never actually came to fruition. Thanks for the clarification!

I think you are half correct. The gateway has nothing to do with verifying the file during a DNS challenge. However, the IP of the machine requesting the cert IS saved with that cert information and made public. Let's encrypt will even warn you during the verification process.