141–150 of 328 posts
A single makefile command is enough to build .deb files, rsync and install them. Rollbacks are trivial.
Put configuration files as well in git and in the .deb
git tags give you a history of releases and also deployments.
I run https://oikolab.com - it's a weather data service with global, hourly historical weather data from 1950 to 16-day forecast. It launched about a year ago and I think it's probably the largest data offering of its kind. I don't have dev ops experience (I still don't know much) so a lot of what I did was to exhaust the limits of the setup before implementing any new infrastructure, sort of learning as I go along,…
I tried to slap together a simple weekend app based on historical weather data by zip code, and never even got to the coding. Just spent most the weekend trying to decipher those API's.
I do it KISS. Deployment for me is always a git hook, usually with a private gitea server. So I have versioning and rollbacks available with a cute UI if necessary. DBs run side by side and are simply backed up regularly with whatever backup solution the VPS offers. That's it. Out of school I put way more effort in building my infrastructure but in reality a good VPS, something like Cloudflare and some app based cach…
I like this answer, but could you expand a bit on why gitea? Never used it myself, but it looks like self-hosted OSS clone of GitHub? If so, my instinct (in terms of KISS) would be to just use GitHub, so I don’t have to set up and maintain my own thing. What made you decide to go with gitea, out of interest?
> git init --bare
On your remote server is all you need to spawn a repo to push to, usually hook examples already included.
The hook can then directly checkout to my live directory, run migrations and restart the server without weird remote automations after every (or specified) push.
Gitea is just a little extra (setup once, touch never thingy) for quick edits and checks (it's a wonderful lightweight piece of software too)
There are so many different options available but they very for different needs.
Regardless, I would assume that you are going to have to pay more for a managed solution that managing everything yourself.
I know the founders at https://releasehub.com/ and it sounds like it might hit that sweet spot for “outgrowing heroku” but “don’t want to do full time devops”.
Earlier quoted context omitted.
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
Naive question: what's the correct way of doing this when you need to cp your content to a dir like /var/www/html that your user doesn't own (when logging in as root is prohibited)? My "spooky" (and probably very stupid) method is an Expect script that lets me supply a password to sudo.
Earlier quoted context omitted.
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
Naive question: what's the correct way of doing this when you need to cp your content to a dir like /var/www/html that your user doesn't own (when logging in as root is prohibited)? My "spooky" (and probably very stupid) method is an Expect script that lets me supply a password to sudo.
> and probably very stupid) method is an Expect script that lets me supply a password to sudo.
The old school sysadmin way of doing this would be to have a dedicated deployment user (ssh pubkey auth only - possibly restricting only specific commands), with a sudoers[.d] configuration to allow that user to run an explicit group commands without a password (NOPASSWD)
Lots and lots of best practice exists specifically to help teams , and especially teams with some normal amount of turnover. The problems of a solo dev are very different than a dev on a team. Knowledge silos don't exist. Distributed expertise doesn't exist. There's no one to mentor, no shared vision to maintain, no intertia to combat. I consult on big complicated team projects. I also manage multiple solo projects.…
> I pay a service to manage backups so I can walk away from a solo project for months and know it's ticking away. Any recommendation of such service?
Earlier quoted context omitted.
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
Naive question: what's the correct way of doing this when you need to cp your content to a dir like /var/www/html that your user doesn't own (when logging in as root is prohibited)? My "spooky" (and probably very stupid) method is an Expect script that lets me supply a password to sudo.
Monitoring - Loads of cron jobs pinging slack (monitoring disk, CPU, Network I/O etc), Healthchecks.io, TurboAPI, Nginx Amplify. Mostly built up over time
DB - Done entirely via migrations. Most of the time they are small migrations so I can do it by running the command directly on the instance
Deployments - GitHub actions to build a docker image (there was a prebuilt template). Watchtower then runs on my server to pick up the new image and that's then deployed automatically. There is no rollback system as I've not needed that so far (and 99% of the time you won't).
Backups - DB backup is done via a cron pushing to AWS S3 Glacier. The app code is stored on GitHub already so no need to back that up. Happy to share the script if you like :)