Permalink
Browse files

Yarb.

  • Loading branch information...
Sam Jacoby
Sam Jacoby committed Dec 17, 2012
1 parent 62c5cb3 commit 650878d1a7b5aae8bf229466462d03015b368b0f
Showing with 32 additions and 10 deletions.
  1. +5 −0 site/content/media/css/GGS.less
  2. +26 −9 site/content/posts/posts/amazon-ec2.html
  3. +1 −1 site/layout/macros.j2
@@ -328,6 +328,11 @@ h3 {
.footnote {
float: footnote;
.small;
+ &>p {
+ display: inline;
+
+
+ }
}
@@ -8,24 +8,41 @@
- ec2
- website
---
-## To that have much, yet more.
-Over the past few days, I've been playing around with Amazon Web Services [AWS](http://aws.amazon.com). Now, I've been a spectacularly satisfied customer of [A Small Orange](http://asmallorange.com) for years, but I've been lately frustrated by the limitations of shared hosting. As I play around with different application platforms (rails, django), and work on developing this site, its clear that I need a bit more than 250MB of space and a restricted shell{{ macros.render_footnote("service", "1") }}.
+_In which my adventures in migrating some small-websites over to Amazon's vaunted services are discussed._
-So, over this weekend, I migrated my sites over to play around with the twelve-months free access provided for AWS `micro-instances`. It's been reasonably enlightening. I've built up a couple of `Arch Linux` images, my preferred distribution, and played with getting environments spinning up for some [applications]({{ content_url("/projects/monotype-app.html") }}) that haven't seen the light of day in some time.
+## To those who have much, yet more.
+
+Over the past few days, I've been playing around with [Amazon Web Services (AWS)](http://aws.amazon.com). Now, I've been a spectacularly satisfied customer of [A Small Orange](http://asmallorange.com) for years, but I've been lately frustrated by the limitations of shared hosting. As I play around with different application platforms (rails, django), and work on developing this site, its clear that I need a bit more than 250MB of space and a restricted shell.{{ macros.render_footnote("service", "1") }}
+
+So, over this weekend, I migrated my sites over to play around with the twelve-months free access provided for AWS micro-instances, that is, tiny cheap servers. It's been reasonably enlightening. I've built up a couple of `Arch Linux` images, my preferred distribution, and played with getting environments spinning up for some [applications]( {{ content_url("/projects/monotype-app.html")}} ) that haven't seen the light of day in some time.
## To Cloud. Or not to Cloud?
Some part of me--or well, most of me--dislikes the cloud. Yes, it's convenient. Yes, Amazon, Rackspace, and all the rest do a damn-good job of things. Yes, it's the future. Virtual machines are great, make sense, are cheap, effecient, and all the rest. In some way, though, it's equal parts exciting and depressing--there is something lost and something gained, when you spin up an instance from yet-another `dashboard`.
-I've always found something striking about that bit of magic that comes with connecting a run-down beige box to an ethernet port in the corner of a room, configuring its permissions, and having it flash its small payload across the waves. This _cloud_, for all the hoopla--is just better word offsite refridgerated storage with 24-hour access. Convenient, sure. But it performs the same calculation as gmail, which trades you convenience for freedom. As much as `AWS` is convenient, it's also inherently less-free.
-Nevertheless, I am a pragmatist--and even if I won't remain with them forever, I thought I should start figuring out how some their systems work. And what can I say? Right now, I have an insanely-fast, scalable, reliable, customizable server, with root access. I can't really complain.
+I've always found something striking about that bit of magic that comes with connecting a run-down beige box to an ethernet port in the corner of a room, configuring its permissions, and having it flash its small payload across the waves. This _cloud_, for all the hoopla--is just better word off-site refrigerated storage with 24-hour access. Convenient, sure. But like gmail, you're trading convenience for freedom. As much as `AWS` is convenient, it's also inherently less-free. Amazon's got your stuff.
+
+Nevertheless, ever the modern man, I am a pragmatist--and even if I won't remain with Amazon forever, I thought I should start figuring out how some their systems work. And what can I say? Right now, I have an insanely-fast, scalable, reliable, customizable server, with root access. I can't really complain.
-At the moment I've got two micro-instances running--one is serving the static pages, the other, a little [typography training app]({{ content_url("/projects/monotype-app.html/")) }} I wrote a few years ago. That won't last long, because you only get one instance free--but I'll switch the nameservers back to `A Small Orange` soon, while continuing to serve the dynamic content from AWS.
+At the moment I've got two micro-instances running--one is serving the static pages, the other, a little [typography training app]({{ content_url("/projects/monotype-app.html/") }}) I wrote a few years ago. That won't last long, because you only get one instance free--but I'll switch the nameservers back to `A Small Orange` soon, while continuing to serve the dynamic content from AWS.
## Reverse Proxies
-Now, I've long heard preached that fine practice--the prudent splitting of dynamic and static content. That makes plenty of sense, really. Or plenty of sense if I ever had much content to serve. In practice, though, It's not something I've ever needed. As someone who has only ever placed things online from some reptilian instinct to share, I have never had any problems with server performance--to say the least. For some time, I ran my personal website from an {{ content_url("/posts/arscons.html") }}. Didn't break a sweat. {{ macros.render_footnote("X40", "2") }}
+Now, I've long heard preached that fine practice--the prudent splitting of dynamic and static content. That makes plenty of sense, really. Or plenty of sense if I ever had much content to serve. In practice, though, It's not something I've ever needed. As someone who has only ever placed things online from some reptilian instinct to share, I have never had any problems with server performance--to say the least. For some time, I ran my personal website from an [X40]({{ content_url("/posts/arscons.html") }}). Didn't break a sweat. {{ macros.render_footnote("X40", "2") }}
+
+There are a million-and-one ingenious ways to do this and I don't understand half of them. All I wanted was a nice, static server that put pages that I made on the internet, and two, have another server throw up some of the dynamic content. That way, I could have one clean server--where I actually knew what was going on--and pass off all of the messy stuff to other computers that had whatever intricate combination of python and everything else that was necessary.
+
+Enter reverse proxies--which are exactly what they sound like. When you ask for something from a server, it scurries of to yet _another_ server, and fetched it from there, passing it through itself and onward to you. So you never know that what you asked for came from some other place. And the proxying server doesn't have to worry itself about whatever complex things you asked for, fobbing you off on some other machine (in my case, the correct AWS instance). Reverse proxies are what really pushed me to AWS, ultimately, as they're not allowed in the shared hosting environment of AWS.{{ macros.render_footnote("option", "3") }}.
+
+At any rate, they're dead simple. These are what mine look like.
+
+`ProxyPass /apps/monotype/ http://ec2-109-21-77-32.compute-1.amazonaws.com/monotype/`
+
+`ProxyPassReverse /apps/monotype/ http://ec2-109-21-77-32.compute-1.amazonaws.com/monotype/`
+
+Exciting stuff, eh? Never done anything easier. Now, I'm not doing any of the fancy load-balancing or the various bells and whistles that real people probably do, but it's been a pleasant introduction. The Apache docs give the rather stern warning: make sure you don't inadvertently turn your server into a _forward_ server, in which case it can be easily hijacked and redirected to all sorts of nefarious ends.
-There are a million-and-one ingenious ways to do this and I don't understand half of them. All I wanted was a nice, static server that put pages that I made on the internet, and two, have another set of instances
{{ macros.render_footnote("service", "1", "Granted, this isn't ASO's problem. They've been absolutely wonderful. I have never interacted with a company--not in tech, not anywhere, with more respnsive customer service. I don't think I've had a ticket go unresponded to for more than fifteen minutes. And I pay $25-a-year for the privilege.") }}
-{{ macros.render_footnote("X40", "2", "At any rate, after realizing that it would be a royal pain-in-the-ass to have `mod_wsgi` compiled against `python3`, while having some virtualenvs that were still using Django 1.3 & Python 2.6 and so on...absolute misery.")}}
+{{ macros.render_footnote("X40", "2", "At any rate, after realizing that it would be a royal pain-in-the-ass to have mod_wsgi compiled against python3, while having some virtualenvs that were still using Django 1.3 & Python 2.6 and so on...absolute misery.")}}
+{{ macros.render_footnote("option", "3", "There are surely some clever ways around this, perhaps using RewriteRule and permanent redirects. I'm concerned what that experience looks like from the client, however. Haven't tried.") }}
+
View
@@ -10,7 +10,7 @@
<sup><a id="{{ target }}-mark" href="#{{ target }}-note">{{ identifier }}</a></sup>
{% else %}
{% markdown %}
-<div id="{{ target }}-note" class="footnote"><a class="footnote-note-number" href="#{{ target }}-mark">{{ identifier }}.</a> {{ content }}
+<div id="{{ target }}-note" class="footnote"><a class="footnote-note-number" href="#{{ target }}-mark">{{ identifier }}.</a> {{ content|markdown }}</div>
{% endmarkdown %}
{% endif %}
{% endmacro %}

0 comments on commit 650878d

Please sign in to comment.