Amazon EC2 instances have seriously made my life a lot easier over the last year. And once you get the hang of the management console it’s actually not as scary as I always thought it would be 😉
I’d like to get away from annual contract bindings and “real” servers that could develop hardware faults. But if you wanted to run Plesk on top of CentOS then this was a bit of a headache – until Parallels launched their Plesk AMI on Amazon Marketpalce. With this release we get the convenience of running Plesk out of the box with a convenient one-click install!
I’ve just tried it and took some notes so I won’t forget. You can also take a peek at the KB Article provided by Parallels which also outlines this procedure:
Step by step instructions
- log into your AWS console
- launch a new instance
- choose the marketplace option (the third one) and search for Plesk
- should come up with this: https://aws.amazon.com/marketplace/pp/B00A85NMY8
- choose your instance and create it
This will take a couple of minutes so grab a coffee and watch out for an email from Amazon confirming the subscription. Note that at the time of writing there’s no AMI for Plesk 11.5 – so we’ll just install Plesk 11 for now and update once we’re up and running.
You will be asked to use an existing Key/Value pair or setup a new one if you don’t already have one. This is essentially a keychain file with which your SSH client can connect to the EC2 instance. You won’t be able to login as root into the instance without this .pem file for security. We’ll download this in a moment.
Each instance is given a longwinded unique URL (such as ec2-54-123-45-227.compute-1.amazonaws.com) with which you can login immediately – but that’s not so good in the long term. Let’s create a static IP instead and associate it with our new virtual friend.
I’m assuming that the above has launched by now, so give the instance a name that describes what you’re doing with it. Onwards:
- create a new Elastic IP (on the left, under Network and Security)
- associate it with your new instance (this is where it helps to have a name, especially if you have more than one instance running)
Amazon will provide a subdomain on which you can access your instance and go straight to the Plesk interface (on that longwinded URL, see above). You will find this in the Marketplace Dashboard (https://aws.amazon.com/marketplace) under “Your Account”, Software Subscriptions. Then click the little plus sign and select “Access this software”. This will get you straight to the Plesk login window.
I need an IP here, so I will tell Plesk about this via the command line. Let’s cover this next. My ficticious IP adrress going forward will be 12.34.56.78. Obvously replace this with your Elastic IP that you’ve setup and associated earlier.
Login to your instance via SSH, making sure you have your .pem file to hand. You can connect via the following command:
ssh root@12.34.56.78 -i yourfile.pem
You’ll get logged in without being asked for a password. Make sure you keep that .pem file in a safe place! This is a good time to yum update your server if you have a few minutes.
Next let’s tell Plesk about that new IP address. Since the setup is all dynamic, Plesk has been created without prior knowledge (or existence) of said IP, so issue the following command:
/usr/local/psa/bin/amazon_setup_ip 12.34.56.78
You’ll get no feedback but it will do the trick.
Now all we need is to find out what the default admin password for Plesk is so we can dive right into the web interface. Thankfully there’s a handy command for that:
/usr/local/psa/bin/admin --show-password
This should give you a cryptic 16 digit password with which you should be able to login to your new instance. Before we do this though, let’s reboot the server for all those updates to take effect:
/sbin/reboot
Once your instance is back, head over to your AWS Marketplace account and “access your software” as described above. This will allow you to access Plesk for the first time, set your IP address and hostname if you have it and create a new admin password.
At this point you can also login to Plesk with your Elastic IP, like so: https://12.34.56.78:8443
First Time Login
Once logged in to Plesk for the first time, you’ll notice that your Elastic IP is not displayed in Plesk. That’s because it’s an external IP pointing to your instance. Internally in Amazon’s network the IP is something else. You must add your Elastic IP here under ETH0 and make it a shared IP if you’d like to host multiple domains on this instance.
You can also give your instance a host name if you have a domain that points at your IP. The default is localhost.localdomain, and you can change this later via Plesk. Don’t forget to add your new (memorable) password at the bottom and hit OK to finish the first run process via the usual Plesk dialogue.
Upgrade to Plesk 11.5
Currently the AMI is only available for Plesk 11, and at the time of writing the current version is 11.5. Le’s update!
Hit Home and check out the System Overview box. This will show you that a later version of Plesk is available (11.5.3 at the time of writing – this may have changed by the time you read this). Choose Install Now and a new window opens on port 8447. You can install the upgrade from here.
This will take a few minutes, and a window may (or may not) offer you log output as it happens. Leave this window open and grab another coffee, it’ll install updates in the background.
Once finished, Plesk will have restarted itself, requesting you to login again. Do so with your new password and enjoy Plesk 11.5 😉
Getting a Plesk License
If you’ve chosen the “Bring your own License” AMI then you need to provide a license key for Plesk to function without limitations. As a Parallels Partner you can get a license from the Partner Portal. If you’re not a partner you can grab a single server license for $40 per month from here:
Alternatively, and great for testing purposes, you can request a 14 day trial license from Parallels here:
Alternatively you can choose to install the “Plesk Power Pack AMI” which is conveniently billed via Amazon at 7c per minute on top of the instance cost. This works out at $50 a month but makes your life a little easier if you wish.
I’ll cover how to add additional storage in this article.
Until then, Happy hosting 😉
Hi Mike, my instance was just super busy all the time, Health Monitor reported 90-100% CPU and Apache constantly as soon as I diverted traffic to it. The instance was slow, occasionally more responsive but crashed a lot. The CPU reading by itself isn’t unusual for a “hard-at-work” virtual system, but as soon as Apache starts being overloaded it means too many hits for the instance to cope with. The only way to whip it into shape was to increase it.
When it was working fine (as an extra large instance I believe) the cost of running Plesk that way was about ten times of what you’d get a small dedicated machine for. I can’t say if this is just the way Plesk behaves on EC2 (unlikely) or if EC2 is just very very very expensive when used this way (more likely).
Let me know your experiences.
Hi Jay, An interesting and informative article as I research all that is required to go the way of AWS. Currently using a dedicated server with Plesk, I wish to replicate my site on AWS using Plesk but have exhausted Google trying to find out if for each additional EC2 instance you create in the future, do you also need to create them using the Plesk AMI and hence be charged another Plesk license fee? Or would the original Plesk AMI used to create your first EC2 instance be used to control all further EC2 instances? I notice your last comment mentions an increased cost for using Plesk with your ‘extra large instance’ so I’m guessing the former? Your help in answering this and best practices would be much appreciated.
Hi Chris, glad you liked it. You would indeed need a separate license for every Plesk instance you run on Amazon, much like you need a separate license for every physical server or VPS you run. You can however replicate an existing instance from an AWS snapshot and spawn off a clone rather than start from scratch. Once your clone is launched, simply change the license to a new “bring your own” in Plesk. It checks every so often with a centralised license server and if two servers are running with the same license you’ll be notified. If you’re planning on using Plesk on Amazon, I’d say use the “bring your own license” flavour.
In regards to performance I have indeed noticed that AWS instances are not as powerful as physical servers. Perhaps it’s the nature of virtualisation, because I’ve noticed the same with XEN cloud servers. To even the odds, you’ll have to use larger AWS instances which will cost you more compared to physical servers.
Let me know how it works out for you!
Hi Jay,
Thanks for your reply. Our reason for asking if we needed a Plesk licence for each AWS EC2 is that we’ve been looking at setting up more than one Plesk powered Instance for high availability, either Active-Active or Active-Passive Failover, however due to the nature of Plesk storing it’s settings (client information, email, dns, domain files etc), we’re finding it difficult to understand a solution whereby all EC2 Instances can be kept in sync with both the website files and these Plesk settings. Have we stumbled into a minefield with this or are we missing an obvious solution to what we are trying to achieve here?
The other way of rethinking this is, are we trying to be overly cautious? We’re migrating from a single dedicated server so just having one EC2 Instance would place us in the same position. AWS is supposed to be pretty reliable, right? And if the Instance were to fail, so long as we have been making regular snap-shots of the Instance, we should be able to spin up a new one and get our site live again pretty quickly, yes?
However, when (hopefully) our site grows, should we not be able to use AWS to spin up more Instances to cope with the growth rather than having a single (very large) Instance. That puts us back into the position above of how to set-up multiple Plesk powered Instances. This may be a whole new tutorial for you to write but any advice would be greatly appreciated.
Hi Chris,
Ah yes, using Plesk in a high availability or cluster setup is the holy grail indeed. I’ve never been able to do it, and sadly Plesk is not designed to be used in this way. Parallels have their own product which is designed to make sure a single Plesk instance doesn’t go down, it’s called Parallels Cloud Server. In this scenario you combine multiple servers into something akin to cluster, and if one physical server goes down the others pick up the slack until you fix the one that’s down. You would need combine 5 physical servers, then create virtual instances inside the cluster which behave like serves, but are not affected by hardware or software failures. It’s costly though: http://sp.parallels.com/products/pcs/
Plesk (and the above scenario) is really designed to host multiple websites and applications, so if your project is a single website then such an infrastructure may be overkill. Amazon offer solutions like Beanstalk which does what you’re looking for on a single-site basis: it deploys with one click, includes a load balancer and auto scales dynamically. New EC2 instances are created on the fly when they’re needed, and taken down again when traffic decreases. It’s another option to explore. Beanstalk will have an impact on how you and your uses administer the project though: http://www.amazon.com/AWS-Elastic-Beanstalk-Developer-Guide-ebook/dp/B007Q4JFE0/
Running a single Plesk instance on AWS (or equivalent, like Windows Azure, Linode, Digital Ocean) as opposed to a single dedicated server has the advantage that you’re protected from hardware failures, so that’s a plus – even without a failover in place. Rolling snapshots are your friend, and misconfigurations are probably the largest cause for errors. But having a “hot standby” Plesk instance is currently not possible as far as I know.
Tell me more about your project, I’m happy to give you my two cents. All the best,
JAY