fpereiro / backendlore Goto Github PK

This is a great read - but when I can to the part on using Vagrant I wondered if you had experience using Docker for development, testing or deployment. Is there anything to share ?

hello

From the README file:

This document is written by Federico Pereiro ([email protected]) and released into the public domain.

First of all, thanks. People publishing to public domain are rare.

Secondly, it is not very obvious at first since that license notice is only visible at the bottom of the file. Additionally, it might cause a bit of concern in places where public domain is not fully recognized or limited (e.g. where moral rights cannot be 100% waived).

So I propose to add a LICENSE file, that deals with those cases by explicitly stating those waivers.
I suggest to use either the Unlicense or the CC0

If you think I am overreaching, feel free to close that issue 😉

I've done multiple web searches and can't seem to find anything but you :-).

In the code you use it to start/restart/stop your node service. I've been just looking for a way to start multiple applications at once and haven't found anything. In particular hugo server. But that isn't your problem, that is mine :-).

Thanks!

To configure HTTPS with nginx: if you own a domain DOMAIN (could be either a domain (mydomain.com) or a subdomain (app.mydomain.com)) and its main A record is pointing to the IP of an Ubuntu server under your control, here's how you can set up HTTPS (be sure to replace occurrences of DOMAIN with your actual domain :):

sudo add-apt-repository ppa:certbot/certbot -y
sudo apt-get update
sudo apt-get install python-certbot-nginx -y

In the file /etc/nginx/sites-available/default, change server_name to DOMAIN.

sudo service nginx reload
sudo certbot --nginx -d DOMAIN

Add the following line to your crontab file (through sudo crontab -e: M H * * * sudo certbot renew, where M is a number between 0 and 59 and H is a number between 0 and 23. This command ensures that every day, at the specified hour, the certificates will be updated automatically so that they don't expire.

On any current Ubuntu/Debian release, this is unnecessary both because the package is already available (python-certbot-nginx for 18.04) and because certbot automatically adds a systemd timer unit, which also randomizes the renewal time in the 12 hour window to avoid renewal congestion:

/lib/systemd/system/certbot.timer:

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/certbot.service:

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Would love to hear your thoughts on performing migrations. Do you have an automated setup/do it manually/ORM does it for you?

Future work: I haven't implemented yet this change since I'm still finding an elegant way to generate, use and clean up CSRF tokens.

The most elegant cleanup procedure is the one that doesn't exist.

You have the session ID. If it satisfies all constraints except not being the session ID, use the session's sha256 (possibly combined with a constant (edit: server-side hardcoded) but attacker-unknown string, so attackers can't bruteforce the session ID that way).

If you want your CSRF tokens to automatically expire (you most likely do), add a timestamp to the sha256 input. Use the unencrypted timestamp plus the sha256 result as your token.

Using /tmp to install mon as well as for logs doesn't seem like the best thing to do, the data is going to get lost if the server ever has to reboot. Just put it in /opt instead.

This is the first "issue" I'm opening up to have a bit of a discussion, so I've got to say that I absolutely love the write up and appreciate that you took the time to share!

I'm trying to understand how your logging mechanism works. By specifying logs = /tmp/MYAPP/logs, do logs from a single node simply get written to the local file system of that node at that path? Would that mean there is no central aggregated (and preferably indexed) logging mechanism?

We used the ELK Stack at my previous company, which can be fully self hosted and is quite powerful when it comes to search and indexing. I'm curious what kind of technologies you've used along these lines?

First of all, thanks for the great post!

It was interesting to me to see that you don't use docker at all. I see docker everywhere, but it's a choice I feel a little ashamed to say I've never really questioned. Was it a conscious choice for you to not use docker (making an image for each service and deploying the container)?
I've heard there might be a performance cost to using docker, but I've never seen anything that points to the cost of using it.
For me the benefits in this regard are the ease of use of updating software for example. The other one being deployment, you just build a new image and 10s later it's deployed.
I'd be curious to know your opinion on the use of docker.

Thanks again for the very informative cover!

Bro，i really like your purposes，but i have to say your file is too long to read。

Never mind,Have a nice day!

do you write API docs in advance? if so, how?

I'd love to use a great working example (for example, if it had a Makefile to run a infrastructure as code Terraform / Pulumi / AWS CDK deployment or something)

Thanks for sharing your experience, this document is amazing👍.

Here is my suggestion:

Have you considered using docker to build and publish which performs consistent environment like vagrant you mentioned,
or even deploy the server into kubernetes cluster the cloud native way.
My experience is that you might not have to worry about local log, disk space, multi process cluster, master worker paradigm, re-fork/monitor worker processes.

This is great, thank you for putting your thoughts + process down.

I'm in a very similar space. I have my own best practises, and there's a lot of overlap.

I have an idea, wondering if you have interest:

We have a kind of competition, like if we had cars, and we bring them to a lot, and show them off to each other.

But with deployable systems like we build. We have some regular competition, low stakes, just out own votes and approval.

Where we prioritize things important to ourselves, and learn from each other.

Some shiny things:

• start up a cluster/web service with a few commands
• automatic scaling, from cloud functions all the way to a scaled up cluster
• graphql integration
• typing (e.g. Typescript) front and and back end
• automatic migration of a complex system to different cloud providers, so there's no vendor lock-in.
• automatic access to sane grafana dashboards

What do you think? This is meant to be for fun and learning, not serious. We make it really inclusive, and show-off what we've learned, and help others up the ladder of complexity.