I followed the instructions on the wiki and used the sample config file and was able to get it to work for http traffic

so my first question is how do i enable https traffic?

Do you intend to have your Apaches only operate in http mode and have aicache terminate https ?

I know that is one option, I believe that is the way i want to go.

great

Now, what about certificate ?

I assume that increases performance as the ssl stops at aicache?

mr.aicache:

Do u presently have an HTTPS certificate for the domain you want ?

mr.aicache:

Yes, it does improve the performance indeed

Customer:

Just so i know, is there a difference in terms of set up difficultly of one approach over the other?

mr.aicache:

Like u mentioned, if it is a new setup, its pretty easy either way.

mr.aicache:

HTTPS *origin* servers

mr.aicache:

Quite often, when accelerating *existing* setups, where ppl already have HTTPS origin servers, they want to keep em

So aicache allows to go both ways

I mentioned earlier, and yes i do already have an ssl cert

Customer:

ok, so if we can configure aicache in either mode, and we get better performance terminating ssl at aicache, i would say let's start there.

mr.aicache:

To simplify, and based on my understanding of what u have stated

It is a very easy thing to do.

A) Have origins all set to go (DONE)

B) have an aicache instance lit and setup to accelerate HTTP (done)

C) obtain the certificate and private key file

D) copy em to aicache instance

E) add additional "listen" directive, specifying HTTPS and pointing to the cert  and private key file

F) uncork a bottle of fine bubbly

Customer:

haha, ok, that does seem pretty straight forward

Customer:

So i have the cert and private key, where do i copy them on the aicache server?

mr.aicache:

copy them to say /usr/local/aicache/

you can call the 2 files anything you like.

BUT - when you using chained certificate, you must call the cert file so that the file name contains "chain" in it

mr.aicache:

You can see if u have "chained" cert file by opening it with an editor. If you have multiple certificates in it, it is a chained cert

mr.aicache:

the manual describes it all in depth

Customer:

I do believe there is an intermediate ca bundle

mr.aicache:

If there's an intermediate ca bundle within the file, it is a chained cert

mr.aicache:

if those are in separate file, you'd need to simply bundle em all into a single chained cert file

mr.aicache:

really easy stuff

mr.aicache:

set it up, modify your local hosts file to point the to-be-tested-domain to aicache instance and navigate to <a href="https://****">https://****</a> in your favorite browser, to make sure it works

Customer:

listen https 123.132.123.21 443 www.abc.com.chain.crt www.abc.com.key AES256-SHA www.abc.com

Customer:

Iadded the cert and key to /usr/loca/aicache, does that mean i dont need to specify the path to the files?

mr.aicache:

The paths are all relative to the directory

mr.aicache:

that one STARTS aicache FROM

mr.aicache:

So if it starts in /usr/local/aicache, then yes, it will find them there, using the "relative" paths

mr.aicache:

To be safe, you can always specificy the complete path to both files

Customer:

gotcha

Customer:

ok, so i added that line to the config file in /root/aicache.cfg

Customer:

did pkill aicache

mr.aicache:

good

mr.aicache:

normally, for 99% of cfg file changes, no restart is req'd. You can "reload" on the fly, without any downtime whatsoever

but modifying listen ports is one change that requires restart

Customer:

ok

Customer:

so two quick questions

Customer:

The "master" config file that aicache uses is the one i just changed, right /root/aicache.cfg

mr.aicache:

yep

Keep a copy of that file please not on the server

Customer:

ok, but what about the config file stored on a sep website

Customer:

Does that auto update or was that simply used to bootstrap aicache

mr.aicache:

There's a way to have a cluster of aicache servers so that they communicate with ea other

mr.aicache:

this is to simplify config management and things like content expiration and stuff

mr.aicache:

We do suggest you retain the cfg file elsewhere, after you arrive at the one you like

You can put it on S3 its in case Amazon instance pukes

Customer:

Right, i see makes sense.

As mentioned you can set up a more fault tolerant setup but its another instance running

Customer:

Right, i think that will be a separate conversation as i saw on your website that you can do cool things with a geo dns set up

Customer:

So i have two more questions

Customer:

First, right now i am testing with two origin instances

Customer:

is there a way to scale up instances and have aicache know about them automaticallywithout requiring me to update the config file

You would need to have Elasdtic IP addresses Pre-configured

For the new instances

mr.aicache:

You can basically wire in 10 IPs

In essence you would pre load them in the config file AI will fail them in the health check until they exist

mr.aicache:

but only have 2 up

mr.aicache:

aiCache will take the 8 that "are not there" out of rotation

Customer:

right, i see, but i thought that each AWS account is only allowed to have 5 elastic IPs

You could set a threshold in ai monitoring to fire off the autoscale request

You can edit and reload the cfg file without downtime.  Simplest would be a script to add the source and do a dynamic reload

Or use rightscale :) Or other automation which we support

It can be done few ways

Customer:

I see, so new instance comes online, first thing it must do is "check-in" with the aicache server by adding itself as an origin and then doing a dynamic reload

Yes

mr.aicache:

if u require assitance, we offer PS engagements to help you to get it all wired/scripted

mr.aicache:

but basics of it all, as you can see, are all very straightforward

Customer:

Sure, makes sense, ok, i think i have a good basic understanding of the set up.