[HN Gopher] Building a static serverless website using S3 and Cl...
___________________________________________________________________
Building a static serverless website using S3 and CloudFront
Author : SanderKnape
Score : 73 points
Date : 2020-02-17 20:22 UTC (2 hours ago)
(HTM) web link (sanderknape.com)
(TXT) w3m dump (sanderknape.com)
| svnpenn wrote:
| I see you are using Hugo 0.62.1
|
| https://sanderknape.com
|
| FYI starting with 0.63.0 the speed has about doubled:
|
| https://github.com/gohugoio/hugo/releases/tag/v0.63.0
| dewey wrote:
| Is the speed it's taking to building the static site usually a
| problem? I don't recall ever waiting for it to be done. Maybe
| my site is too minimal to see a difference
| (https://annoying.technology).
| weego wrote:
| No, circle goes from clean state to npm install, scss
| compile, drags content from contentful and then runs the Hugo
| build and upload to S3 in under 30 seconds for our site. Most
| of the time is npm flaffing about.
| heinrichhartman wrote:
| I have compile times of >30 seconds with Jekyll blog [1,2].
| This is an issue. It adds a lot of friction to the
| edit/preview loop.
|
| BTW: I just moved it to Netlify since reading this thread.
| Took me ~5 minutes.
|
| [1] https://github.com/HeinrichHartmann/HeinrichHartmann.gith
| ub....
|
| [2] https://www.heinrichhartmann.com/
| dewey wrote:
| FWIW I'm getting a "certificate does not match
| *.netlify.com" SSL error on your site.
| heavyset_go wrote:
| Just use Netlify, it's free, you can hook it up to a GitHub
| repository and they'll handle your Let's Encrypt certs for you.
| rexreed wrote:
| Can someone please provide practical advice on moving from a site
| hosted on Wordpress using all the plugins to a static hosted
| site? It seems unbelievably complicated.
|
| My non-technical employees and partners like Wordpress. We like
| the plugins that make web development easy and not arcane.
|
| But we don't like the fact that every page requires basically a
| database read. Yes, we use WP-SuperCache, and it's ok.
|
| But why oh why is it so hard to do the editing on Wordpress and
| the publishing on a Static site? Anyone with some real guidance
| here?
|
| We want the people who come to the site to get the static
| experience while the people who edit the site to get the
| Wordpress experience.
| heavyset_go wrote:
| > _My non-technical employees and partners like Wordpress. We
| like the plugins that make web development easy and not
| arcane._
|
| Use what works for your teams. Apparently, that's Wordpress and
| that's okay.
|
| > _We want the people who come to the site to get the static
| experience while the people who edit the site to get the
| Wordpress experience._
|
| Stick a caching proxy or CDN in front of it, not just a
| Wordpress cache plugin. Something like CloudFlare would help
| you out.
| oconnore wrote:
| In a previous life I worked on a site that had a private
| Wordpress instance that was scraped and cloned to a more or
| less static site.
|
| You can either do this explicitly using a small scraper tool,
| or implicitly using aggressive reverse-proxy caching rules.
| rexreed wrote:
| Sounds pretty intensive. Every page would need constant
| scraping as links update and sidebars change, wouldn't they?
| oconnore wrote:
| I think you might be overthinking it. Just drop cache after
| publishing.
|
| Maybe you're doing something more complicated that isn't
| amenable to pseudo-static?
| BossingAround wrote:
| > Can someone please provide practical advice on moving from a
| site hosted on Wordpress using all the plugins to a static
| hosted site? It seems unbelievably complicated.
|
| Oh I'm sure it is. Static website is just that--static. You
| don't have a database, and that is a great thing, but that also
| means you can't store stuff like users, comments, articles to
| be published in the future, etc. out of the box.
|
| You can do all of that of course, but it's going to be
| difficult, and you're gonna plug non-static parts to your
| static website (such as plugging the comments part). All in
| all, you can't expect to have all the advantages of static
| websites as well as Wordpress.
|
| I personally simply took my content from Wordpress and built a
| new website with gatsbyjs. It's fast, clean, and entirely in
| React + Typescript. It has no dynamic parts, though. If you're
| a business and your Wordpress site is production critical, who
| knows, you might not want to migrate. You might also want to
| explore alternative solutions, like split some parts of your
| Wordpress blob into several static websites, and keep the main
| WP site with less content that's easier to manage... There are
| a number of possibilities.
| weejewel wrote:
| Just put cloudflare or a similar service in front of it and
| tada, your host handles only a few requests per minute.
| rexreed wrote:
| Is there any quick guide or plugin for front-ending Wordpress
| with Cloudflare? Sorry if this is a LMGTFY or RTFM but
| there's legit lots of conflicting advice.
| weejewel wrote:
| You should set this up from within cloudflare. What they do
| is essentially download your website from a private url,
| e.g. blog.mydomain.com and publish it under your public
| domain, e.g. myblog.com.
|
| In theory, wordpress doesn't even know it's happening. Make
| sure to disable any caching plugins as well, you won't need
| them anymore.
| ThePhysicist wrote:
| You can use wget or curl to make a static copy of your
| Wordpress site and publish that. There are some small caveats
| (all files need to be reachable via links or you will have to
| manually tell wget where to find them) but it's a great
| solution if you want the convenience of Wordpress and the
| security of a static website.
|
| I set up such a system for my old research group during my PhD
| (as they were not allowed to use Wordpress directly) and they
| are still using it 8 years later:
| http://iramis.cea.fr/spec/Pres/Quantro/static/index.html
|
| Back then I wrote a simple Wordpress plugin that would create
| an empty file when a button was pressed in the UI, and I had a
| cron job that was executed once per minute, checked if the file
| existed and if so deleted it and copied the new version of the
| dynamic website to the static server.
| meritt wrote:
| Static site generation is just a trendy reinvention of caching.
| Put a CDN in front of your site, or run one of the many
| wordpress cache plugins [1] and point your httpd at the cache
| directory instead of PHP.
|
| [1] https://wordpress.org/plugins/static-html-output-plugin/
| manigandham wrote:
| 1 - Use a CDN and cache your html on the edge. 5 mins of work
| for infinite read scaling and no other changes.
|
| 2 - You can run a process to crawl your WP site and output all
| the pages as static files, then upload those for hosting.
| WP2Static handles that for you:
| https://wordpress.org/plugins/static-html-output-plugin/
|
| 3 - Use Wordpress as a "headless" CMS for editing and storing
| content, then use one of the modern static site frameworks to
| get content over JSON/HTTP from Wordpress while building your
| site.
|
| I'd go for option 1 and call it done.
| petra wrote:
| Hardypress.com is an easy option.
| meritt wrote:
| It's amusing to me how programmers look back with disdain at web
| development in the 90s and how "you just uploaded files to a FTP
| server" and now we've circled back to the same thing, just with a
| whole lot more plumbing in the middle.
| rolltiide wrote:
| that is comical but doing what is described in this post in the
| 90s would have required load-balanced tower PCs strategically
| located all around the world, with another few computers acting
| as a load balancer, all maintaining copies of the website and
| cached server responses, and an expensive SSL certificate
|
| we get all that for free now or 50 cents a month, just for
| static websites
|
| there is almost no comparison, except for acknowledging that
| the plumbing sucks, all of which you can make better if you
| want.
| WrtCdEvrydy wrote:
| But it's AWS-branded plumbing now!
| znpy wrote:
| it's in the cloud!
| awb wrote:
| For me, Netlify is the right mix (I'm not affiliated with
| them). It has the 90s ease of use with modern tools and
| performance out of the box. It's simple to upload files or sync
| a repo and it it's free. I'm not sure why anyone would host a
| static website on the AWS stack.
| ilovenetlify wrote:
| Yup. Netlify have nailed it.
| xienze wrote:
| > I'm not sure why anyone would host a static website on the
| AWS stack.
|
| Well, I do that, so I guess I'll chime in.
|
| First and foremost is the idea of not tying your site's build
| process and hosting to a company that could go under. Yes,
| Amazon could, but if I had to bet Netlify will either cease
| to exist, be bought out, have its free offering
| discontinued/changed/etc. long before that.
|
| Second is that sometimes your site's build process is more
| complicated than what Netlify provides. For example, my site
| is a static Hugo site, which Netlify supports, but there's
| one crucial step in the build process where I turn my
| "resume.html" page into "resume.pdf" -- I have to run a
| Docker image that starts headless Chrome in order to render
| the PDF properly. As far as I can tell, that can't be rigged
| up in Netlify.
|
| Finally, I was able to learn a lot about AWS by hosting my
| site this way -- setting up a Lambda to listen for GitHub
| commits, using the AWS API to launch an EC2 instance to build
| my site, how to configure S3 and CloudFront to serve up
| content properly, etc. And at the end of the day I get a site
| that I have complete control over and is approximately free
| to run.
| JeanSebTr wrote:
| For the first point, I'd say it's best to save the setup
| time by using a service like Netlify and keep that for _if
| /when_ they shut down.
|
| For the PDF, there's probably some service that could be
| used to wire that quick. But I agree that can be the cut-
| off point where it might be simpler for some to use docker.
| mprev wrote:
| Who is downvoting this? It seems to be a polite answer to
| the question asked.
| meritt wrote:
| I didn't vote on the comment but it came across to me as
| emblematic of what I feel is "wrong" with technology
| trends over the past decade. Where instead of solving
| business problems it's mostly building tools on top of
| tools or reinventing the wheel in the latest
| language/ecosystem. Programmers rarely produce anything
| of value anymore, but instead parade around their mastery
| of an increasingly complex toolchain that delivers the
| same end result.
| wexxy wrote:
| Well... technically netlify is AWS behind the scenes isn't
| it?
| endorphone wrote:
| Does it matter? To people at our distance from it the
| process is a magical one where a git repo becomes a
| website. What technology stack they use, on which services,
| etc, is an abstraction that isn't particularly relevant to
| us.
| bathtub365 wrote:
| Until it breaks. Then you are either completely stuck, or
| trying to untangle the thick, multilayer abstraction
| hosting your "static" website.
| endorphone wrote:
| If it broke it would take me all of minutes to have it
| hosted elsewhere. There is essentially zero lock-in with
| the service, even if you're using some of more
| complicated build steps.
| philistine wrote:
| I'll give you my answer: I optimized for the lowest cost for
| a solution I could forget about. And not any suspicious free
| option like Github pages that might go away next year. True
| lowest cost hosting for a static website. AWS was the
| cheapest for me.
| daxfohl wrote:
| And there seems to be a rash of "whoa I stumbled on my old
| site's url at {90's hosting provider} and it is still up and
| running after all these years" comments lately. (And loads
| instantaneously with no UI framework).
| Frost1x wrote:
| Tech suffers significantly from memory loss.
|
| To be fair, when you dive deep into complexity, it's easy to
| get lost in the weeds. The trick is to remember what you're
| doing and why you're doing it so you don't lose sight of
| goals while chopping through the complexity jungle.
| saagarjha wrote:
| > programmers look back with disdain at web development in the
| 90s and how "you just uploaded files to a FTP server"
|
| Since when? I thought most people liked the simplicity and low
| barrier to entry...
| animalgonzales wrote:
| and buckets of cash for amazon...
| simonw wrote:
| How is this so complicated? I shudder to think of the amount of
| developer hours wasted by the weirdness and complexity of AWS.
| Really wish they would prioritize usability and developer
| experience.
| harryh wrote:
| AWS's business isn't making simple things like this easy for
| solo practitioners who are never going to spend any money.
|
| Their business is making big complicated things possible for
| companies that are going to spend a lot of money and don't care
| about a small amount of incidental complexity.
| lawik wrote:
| Probably because it is built on tools that are made to scale
| arbitrarily and solve a large amount of very general needs.
| This need is simple, the tool is not built for simple needs
| though it can meet them.
|
| I dislike the UX of AWS but the complexity here isn't strange
| to me. I bothered to set up the first bit of this (didn't need
| sub-dir index files so didn't realize it was a problem) since I
| wanted a simple storage, simple deploy and good resilience.
|
| My site has been hit by HN a few times now and it hasn't been
| an issue. Fairly set and forget. But the start is annoying.
| [deleted]
| nsporillo wrote:
| I have my personal website deployed to S3 and my DNS in Route53
| with a Travis CI commit hook that will upload my files and
| update the permissions automatically when I push changes to
| Github.
|
| Only costs ~$27/year to have a domain($15) and a static website
| deployed to S3/R53 ($1/month), which I've found to be fairly
| reasonable for the level of reliability I can expect.
|
| I admit it is complicated up front but once it is setup and
| updates are automated it is really nice to not need to worry
| about self hosting, hardware, VPS', etc just for a simple
| website.
| Gys wrote:
| > push changes to Github
|
| Or create an organisation on Github and publish this website
| as a Page. It is simple and it is free.
| nsporillo wrote:
| Certainly not a bad idea, but in my case I care to own the
| domain because I also use it when naming Java packages for
| the projects I write. Since I'm already paying for the
| domain, I figure I might as well use it for my actual
| website too. I've found S3 and Route53 to be the most cost
| effective for my particular use case.
| Gys wrote:
| It is easy to connect your own domain to a Github Page
| ;-)
| manigandham wrote:
| Github Pages support custom domains for free.
| sdinsn wrote:
| Github Pages supports domains
| chindtooo wrote:
| Use google Cloud Run though I love Netifly.
| brown9-2 wrote:
| One thing that these guides on using S3 never mention is to make
| sure to set alerts if the cost of the bucket grows too fast, i.e.
| your site gets popular.
| manigandham wrote:
| Static sites are overrated for most cases. Often you still need a
| backend for editing with non-technical folks or just easier
| handling of media, etc so you're now running a server-side
| instance of some blog or CMS while adding a whole new detached
| frontend layer.
|
| With things like Cloud Run that can run a container on-demand for
| every request, it's easier to just stick with regular Wordpress
| or Ghost server-side stacks.
| saagarjha wrote:
| > Static sites are overrated for most cases. Often you still
| need a backend for editing with non-technical folks or just
| easier handling of media, etc so you're now running a server-
| side instance of some blog or CMS while adding a whole new
| detached frontend layer.
|
| Not for my blog.
| manigandham wrote:
| _most sites_.
|
| If you're editing markdown files with only text and running a
| simple convert to html then it'll work fine, but ghost/WP in
| a container would work just as well.
| spectramax wrote:
| What's wrong with old school apache server running on a $5/month
| DigitalOcean droplet?
| chindtooo wrote:
| I prefer Google Cloud Run and it need not be 100% static though
| it should be stateless.
| coolsunglasses wrote:
| Here's my terraform-ization of an S3 + Cloudflare setup for SSGs.
| I use Zola but that's incidental.
|
| https://gitlab.com/bitemyapp/statically-yours
|
| There's a weird bug with the `tf init` but it can be worked
| around by running `tf init`, deleting the providers in
| `.terraform`, then running again. Hashicorp has an open bug for
| the problem I think.
|
| I could probably clean it up more but this has been okay for a
| couple sites I run.
| calvinmorrison wrote:
| I would like to just mention that github does static site hosting
| for free. I have used it for a few years. Never had a problem.
| Static, Free, probably not going out of business in the next 5+
| years, domain is my only cost.
| saagarjha wrote:
| And they can probably handle your traffic, too!
| JoshTriplett wrote:
| True, but they reserve the right to prohibit sites that use up
| a non-trivial amount of bandwidth, or that have commercial
| purposes, or various other reasons.
|
| It's a great service, but I wouldn't count on it as your
| primary hosting.
| riffic wrote:
| Many providers do free static hosting:
|
| https://www.slant.co/topics/2256/~best-static-website-hostin...
| [deleted]
| jposer wrote:
| this was literally what I was doing today and if I'd just checked
| hacker news it would have saved 3 hours of faffing with Lambda
| oxplot wrote:
| Still can't do the same without paying hourly for a load balancer
| on Google Cloud. C'moon Google!
| k__ wrote:
| Amplify really eases the pain with this.
| ttoinou wrote:
| Anyone knows how I could measure website performance all over the
| world averaged across multiple runs both for webpage and
| downloading huge file (100Mo) ? To verify that the CDN is indeed
| faster than my current hosting solution
| philfreo wrote:
| > The redirect logic provided by the S3 website endpoint can be
| moved to a Lambda@Edge function.
|
| The post here is using Lambda@Edge to handle pointing
| example.com/about/ to example.com/about/index.html
|
| However there's a lot more you can do / may want to do with
| Lambda@Edge if you're hosting a Cloudfront+S3 website.
|
| I just wrote up how I set up a system to make managing server-
| side redirects (e.g. 301s from /old-page to /new-page) easier via
| Lambda@Edge.
|
| https://news.ycombinator.com/item?id=22351484
|
| https://engineering.close.com/posts/redirects-using-cloudfro...
| jillesvangurp wrote:
| I did some redirects without lambda's last year using s3
| routing rules, which kind of worked. As figuring out this and
| several other things, I also wrote up some details on this.
|
| https://dev.to/jillesvangurp/using-cloudfront-s3-and-route-5...
|
| IMHO, Amazon should be ashamed of themselves for making it so
| unbelievably convoluted and hard to host a simple website on
| cloudfront. It's the one thing almost every website out there
| has to solve and they made it super painful to get this right.
| mlmitch wrote:
| The complicated stuff seems predicated on this:
|
| "However, the S3 website endpoint is publicly available. Anyone
| who knows this endpoint can therefore also request your content
| while bypassing CloudFront. If both URLs are crawled by Google,
| you risk getting a penalty for duplicate content."
|
| I'm curious if anyone has experienced these issues in practice.
| jeffadotio wrote:
| CloudFront has one-click direct bucket access restriction.
| tyingq wrote:
| You can specify the canonical url in the HTML. Then it's not an
| issue.
|
| https://support.google.com/webmasters/answer/139066?hl=en
| lawik wrote:
| I run the setup of S3 + Cloudfront and never ran into their
| index problem because I'm not trying for URLs without document
| file extensions.
|
| I assume that's the reason for really wanting index redirect in
| directories. Pretty URLs, I didn't feel the need. There are
| other valid reasons too I'm sure. But my needs diverged from
| the article even earlier than SEO penalties.
| mlmitch wrote:
| The pretty URLs thing is confusing me now too. AWS lets you
| configure the buckets to do the pretty URLs.
|
| https://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsit.
| .. https://docs.aws.amazon.com/AmazonS3/latest/dev/IndexDocum
| en...
|
| I put up a Jekyll site on s3/cloudfront recently and it seems
| to work well.
|
| Anyway, I'm still wondering about the consequences of the
| naked s3 endpoint being available.
| ehonda wrote:
| Host a static website the HN way:
|
| 1. Buy the cheapest most unsustainable VPS ipv4 deal out there.
|
| 2. Make A record and WWW record and point domain to your new
| fangled server.
|
| 3. Configure server:
|
| apt-get install nginx goaccess
|
| cd website
|
| cp * /var/www/html
|
| Yearly maintenance required: apt-get update, apt-get upgrade
|
| reboot
|
| View traffic stats: goaccess -f /var/log/nginx/access.log
| thinkxl wrote:
| > Host a static website the HN way
|
| Gatekeeping alert!
|
| Fortunately, there is more than one way to do things. I've been
| in HN for a while now and I don't do any of this. I was doing
| it when I wanted to learn, but now I need to get a project
| launched without any burden so I deploy it to ZEIT Now which is
| not the same as OP, but you get the idea.
| nsporillo wrote:
| The last time I tried to maintain a personal VPS I was using it
| for a Jenkins build server so users could obtain the latest
| artifacts of some open source programs I work on. That burned
| me after it got exploited using a Jenkins RCE and a bitcoin
| miner was installed on the VPS.
|
| Also, the cheapest VPS you can find likely won't ever achieve
| the level of scale your static website in S3 could achieve. In
| the rare event you get a lot of web traffic, you're only hosed
| if AWS is hosed.
| eli wrote:
| S3 isn't actually that great at serving a ton of traffic
| without a CDN in front of it
| capableweb wrote:
| You gotta receive a ton of traffic for Nginx to stop serving
| static files. I'm pretty sure most of the static websites
| today could survive on a lite Nginx vps with minimal tuning.
|
| Also, i rather have my server go down than to receive a
| larger bill from aws, but that all depends on your use case
| obviously
| nsporillo wrote:
| Yeah this is probably true, I've never actually had a nginx
| instance be overwhelmed myself. I just don't know how much
| I trust VPS providers that aren't charging a premium
| $5+/month to deliver quality reliable performance.
|
| The best part of S3 + Route53 is your costs are basically
| constant. $.50 a month for the hosted zone and then you pay
| pennies on the dollar for GBs of data transfer. In theory
| your bill could balloon if you had a hefty static website
| or some big files left public in your buckets and someone
| constantly downloaded it.
| veeti wrote:
| Replace nginx with Caddy for zero config HTTPS.
| Tilian wrote:
| It's amazing how truly unreliable ultra-cheap VPS providers can
| be. You're lucky if you even get an upfront notice before they
| decommission hardware you are relying on, or the entire company
| just disappears overnight.
|
| Usually you get what you pay for.
| nerdkid93 wrote:
| Google Cloud gives you 1 free f1-micro compute instance.
| Coupled with a CDN like Cloudflare or Netlify, it should be
| beefy enough for a static site.
| WJW wrote:
| At that point, why even keep the compute instance? You can
| get them to host your static content entirely.
| jskrablin wrote:
| Or setup a Google cloud domain named bucket and put
| Cloudflare in front.
| manigandham wrote:
| You can also just get a micro instance from the major cloud
| providers. Just as cheap, and more reliable and usable with all
| the console tools.
| mr_toad wrote:
| For extra work add a let's encrypt client, configure Nginx to
| do ssl, and set up automatic renewal.
| joking wrote:
| there are literal dozens of sites who offer free static site
| hosting, from github pages to firebase hosting, why advantage
| you get using a VM?
| amerkhalid wrote:
| Server side stats instead of Google Analytics is big one,
| imo.
| tastroder wrote:
| A machine I can actually use, portability. I have enough
| servers, adding nginx and certbot to one isn't hard. Adding
| instances and load balancing isn't either should it be
| warranted. The "serverless" approach is the new one and thus
| the one that should seek justification.
| iudqnolq wrote:
| Serious question: how much more maintenance is required? Could
| I get away with unattended-upgrades and nginx+wsgi+PostgreSQL?
|
| I ask because actual servers seem like dark magic to me so I
| want to try to build a product with them, but I can't find
| anywhere if it's possible to run a reasonably secure server
| without years of studying.
| ehonda wrote:
| you can change the ssh port and use a ssh key instead of a
| password. Don't worry about a firewall or fail2ban. That's
| about all. Also run everything from root.
|
| Repeat above steps once vps provider goes out of business (as
| someone else also pointed out)
| e12e wrote:
| > you can change the ssh port and use a ssh key instead of
| a password.
|
| I'd advice against changing the ssh port - I don't think
| the (small) inconvenience is worth the (tiny) benefit to
| obscurity.
|
| I would _always_ recommend turning off password
| authentication for ssh, though.
|
| (along with disabling direct root login via ssh, but root-
| with-key-only is now the default - and if you already
| enforce key based login, it's a bit hard to come up with a
| real-world scenario where requiring su/sudo is much help
| for such a simple setup).
|
| I would probably amend your list to include unattended-
| upgrades (regular, automated security-related updates - but
| I guess that's starting to be standard, now?).
|
| You will probably need an ssl cert, possibly from
| let's-encrypt.
|
| At that point, with only sshd and nginx listening to the
| network - avenues of compromise would be kernel exploit
| (rare), sshd exploit (rare) or ngnix exploit (rare) -
| compromise via apt or let's-encrypt (should also be
| unlikely).
|
| Now, if the site is dynamic, there's likely to be a few
| bugs in the application, and some kind of compromise seems
| more likely.
| iokanuon wrote:
| Anecdotally, changing the ssh port on a very low-budget
| VPS is worth the effort because the CPU time eaten by
| responding to the ssh bots can be noticable.
| banana_giraffe wrote:
| I'm more familiar with AWS. There I just firewall SSH to
| just my IP (with a script to change it for the laptop
| case, or use mosh), and thus spend no CPU time responding
| to ssh bots.
|
| Do VPS providers offer some sort of similar firewall
| service outside your instance?
| e12e wrote:
| That's not something I had considered - I suppose the
| handshake does take up some cpu.
| geofft wrote:
| If you're serving static content, installing Apache, nginx,
| or any other web server will do just fine. Make sure to set
| the document root to a directory you're fine being public.
|
| If you're running something dynamic like WordPress, stay
| extremely on top of patches, unfortunately, and be super
| cautious about what plugins you use. (This is one of the
| better reasons to use a static website.)
|
| If you want to run a Postgres for your dynamic website,
| configure it to listen only to localhost or only via UNIX
| sockets.
|
| Make sure you keep your software up-to-date. unattended-
| upgrades is a great idea for OS-provided software.
|
| Be careful about where you get software from. More than just
| "get it from somewhere trustworthy," the big concern here is
| to get it from someone who is applying software updates. For
| most OS-ish things, you want to get them from your distro;
| try to avoid downloading e.g. PHP from some random website,
| because you won't get automatic updates. For a few things -
| especially things like WordPress - I wouldn't trust the
| distro to keep up, largely because the common practice is to
| release security fixes by releasing new versions, and distros
| are going to want to backport the fixes, which is slower and
| not always guaranteed to work.
|
| As another commenter mentioned, turn off remote password
| logins and set up SSH keys. (Most VPS providers will have
| some form of console / emergency access if you lose access to
| your SSH keys.)
| jjoonathan wrote:
| Yes, you can absolutely do that, but shouting that message
| from the hilltops isn't a good business model in an industry
| with ADHD.
| mr_toad wrote:
| It's not that bad. A day or two initially, then an hour or
| two every six months, depending how much work you put into
| automating it. It's definitely a good way to learn.
|
| Write everything down! Every command you type. You don't want
| to come back in sixth months time and have to relearn what
| you did the first time.
|
| If you're feeling ambitious you can script almost the entire
| deployment from provisioning a machine through to rsyncing
| the content. It's pretty fun to run a bash script or two and
| see an entire server pop up.
| dragonwriter wrote:
| > Buy the cheapest most unsustainable VPS ipv4 deal out there.
|
| [...]
|
| > Yearly maintenance required:
|
| Well, presumably, find the new cheapest, most unsustainable VPS
| ipv4 deal, the previous one not having been sustained.
| jeffadotio wrote:
| I recently wrote a detailed tutorial on dirt-cheap professional
| hosting with AWS. It may be useful to anyone that found this
| article informative.
|
| https://jeffa.io/tutorials/inexpensive_aws_hosting.html
| dayjah wrote:
| I've had to do this multiple times over the past two years. It's
| always a shock to me how hard it is.
|
| The Lambda@Edge functions especially. They have 4 phases they can
| be injected into: viewer-request, origin-request, origin-
| response, and viewer-response. If you put your code in the wrong
| place you get hard to debug issues. Additionally you cannot
| "annotate" a request, so a decision at say "viewer-request"
| cannot pass information to later stages.
|
| Also, deployments take 15 minutes at least which just further
| frustrates the debugging process.
| eastbayjake wrote:
| This was actually one of my most delightful experiences with
| Azure Functions and Microsoft's API Management solution -
| overhead does not make it the right fit for every serverless
| architecture, but it did make orchestrating functions in this
| way a lot easier
| zackbloom wrote:
| Have you tried Cloudflare Workers and Workers Sites? I believe
| they fix both issues.
| loevborg wrote:
| I totally agree. CloudFront is maddeningly anemic, with hacks
| required to do the most basic things. Nginx/Varnish
| configuration is bad but CloudFront is worse. I wonder how much
| better competitors like Cloudflare and Fastly are.
| jjoonathan wrote:
| _Every_ AWS service is shockingly crusty. Even after spending
| years on AWS calibrating my expectations downwards, it
| regularly finds ways to surprise me.
|
| I know, I know. For developers it beats obtaining permission
| every time you want to spend $5/mo on some plumbing and for
| managers it beats getting fired because you chose Google cloud
| and they canceled it the next year. Still... ugh.
| welder wrote:
| It's much simpler to use GitHub Pages + Cloudfront (optional).
| abstrct wrote:
| Ya, I'm trying to understand what the downside to github pages
| is compared to this strategy. Can anybody elaborate on what I
| might be missing?
| philistine wrote:
| I'd rather be a paying customer and know I'm not going to
| lose my setup because of some reason.
| gitgud wrote:
| What benefits does this have? in comparison to much easier
| solutions like; Netlify, Github Pages etc..
| simlevesque wrote:
| You should use Amplify, it solves allk those problems.
| davidweatherall wrote:
| For anyone who is hosting .html files and doesn't want to have to
| put index files inside directories, the "trick" with s3 is to
| rename the file to the name without the html extension, and
| change the Content Type to text/html.
|
| Earlier today I modified the popular jakejarvis s3 sync github
| action to allow for this during my CI/CD process.
|
| https://github.com/davidweatherall/s3-sync-action
| shapeshed wrote:
| Deploying static sites is the original and best candidate for
| engineers overengineering
___________________________________________________________________
(page generated 2020-02-17 23:00 UTC)