Posted by lee jones on Feb 5, 2014 in Azure, Other
I recently had the need to run some PowerShell scripts against a new VM created in Windows Azure using PowerShell Remoting. I thought this would be a simple enough job (and in truth, it is), but you need to know a couple of things. By default, PowerShell uses active directory to identify and authenticate users, but of course standalone Azure VM’s aren’t part of a domain. Therefore you’ll need to add the public IP address of the VM to the trusted hosts on your client. From the Azure portal, open port 5985 for PowerShell (the portal should open 5986 by default). To do this, go to: Virtual Machines > YOUR VM > Endpoints > ADD. Complete the resultant dialog: From the client machine, start PowerShell and type Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44' 1 Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44' Obviously substituting the IP address of the Azure VM you obtain from the Azure Portal If you already have trusted hosts, use –Concatenate to avoid overwriting the others. To be sure, Get-Item -Path WSMan:\localhost\Client\TrustedHosts 1 Get-Item -Path WSMan:\localhost\Client\TrustedHosts Should show you the entry you just created. Now, to connect to the Azure VM and start the PowerShell session: Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\USERNAME 1 Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\USERNAME Substitute in the username you created in the Azure portal when creating the VM (or any user you’ve since set up on the box with the relevant permissions) and you should be presented with a login box to confirm the password. Once that is done, your PowerShell session should be active. Happy...
Read More »
Posted by lee jones on Jan 21, 2014 in Azure
I recently ran into a problem creating a storage account using PowerShell. The rather obscure error I was getting was: New-AzureStorageAccount : Specified argument was out of the range of valid values. 1 New-AzureStorageAccount : Specified argument was out of the range of valid values. After lots of digging about coming up blank at the likes of Bing, Google and Stack Overflow I worked out the root cause – the name I was using for the storage account exceeded the 24 character length imposed by Azure! Simple error that I should have spotted, and attempting to create that environment in the portal surfaced the underlying cause immediately, but error messages like this really do not help. Nothing like a helpful error message is...
Read More »
Posted by lee jones on Jan 13, 2014 in AWS, Cloud
This blog post covers the process of automatically starting and stopping an EC2 instance at a given point in time. In my case I needed to spin up an instance, do some work and then shut it down afterwards. This is perfectly suited to AWS and cloud computing and typifies the ethos of elastic scaling and capacity-on-demand. In order to start/stop an instance you will need to make use of the AWS Auto Scaling capabilities which are both straight-forward but very, very powerful. The first thing that you’ll need to do is set up the Auto scaling tools. Amazon have an excellent step-by-step guide posted here If done correctly you should be able to open a new command prompt (or powershell terminal) and type as-cmd 1 as-cmd You should get a listing of all auto-scaling commands: Command Name Description ------------ ----------- as-attach-instances Attaches Instances to Auto Scaling group as-create-auto-scaling-group Create a new Auto Scaling group. as-create-launch-config Creates a new launch configuration. as-create-or-update-tags Create or update tags. as-delete-auto-scaling-group Deletes the specified Auto Scaling group. as-delete-launch-config Deletes the specified launch configuration. as-delete-notification-configuration Deletes the specified notification configuration. as-delete-policy Deletes the specified policy. as-delete-scheduled-action Deletes the specified scheduled action. as-delete-tags Delete the specified tags as-describe-account-limits Describes limits for the account. as-describe-adjustment-types Describes all policy adjustment types. as-describe-auto-scaling-groups Describes the specified Auto Scaling groups. as-describe-auto-scaling-instances Describes the specified Auto Scaling instances. as-describe-auto-scaling-notification-types Describes all Auto Scaling notification types. as-describe-launch-configs Describes the specified launch configurations. as-describe-metric-collection-types Describes all metric colle... metric granularity types. as-describe-notification-configurations Describes all notification...given Auto Scaling groups. as-describe-policies Describes the specified policies. as-describe-process-types Describes all Auto Scaling process types. as-describe-scaling-activities Describes a set of activit...ties belonging to a group. as-describe-scheduled-actions Describes the specified scheduled actions. as-describe-tags Describes tags as-describe-termination-policy-types Describes all Auto Scaling termination policy types. as-disable-metrics-collection Disables collection of Auto Scaling group metrics. as-enable-metrics-collection Enables collection of Auto Scaling group metrics. as-execute-policy Executes the specified policy. as-put-notification-configuration Creates or replaces notifi...or the Auto Scaling group. as-put-scaling-policy Creates or updates an Auto Scaling policy. as-put-scheduled-update-group-action Creates or updates a scheduled update group action. as-resume-processes Resumes all suspended Auto... given Auto Scaling group. as-set-desired-capacity Sets the desired capacity of the Auto Scaling group. as-set-instance-health Sets the health of the instance. as-suspend-processes Suspends all Auto Scaling ... given Auto Scaling group. as-terminate-instance-in-auto-scaling-group Terminates a given instance. as-update-auto-scaling-group Updates the specified Auto Scaling group. help version Prints the version of the CLI tool and the API. For help on a specific command, type ' --help' Getting started Now you can start implementing auto scaling. Auto scaling on a schedule requires a number of components which form the what, where and when to scale: 1. A launch configuration (the ‘what’) 2. A scaling group (the ‘where’) 3. A schedule policy (the ‘when’) 1. [WHAT] Create the launch configuration From your command prompt enter the following command: as-create-launch-config "screenshotter-launch-config" --image-id "ami-12345678" --instance-type "m1.medium" 1 as-create-launch-config "screenshotter-launch-config"...
Read More »
Posted by lee jones on Dec 2, 2013 in AWS, Cloud
The more I play with (and love) AWS as a platform, the more the significance and power of IAM becomes. This post outlines IAM and how it should be used effectively within Amazon’s cloud environment. What is IAM? IAM, or Identity and Access Management is the primary means of securing users, groups and permissions. IAM is complimentary to services such as security groups and Access Control Lists (which govern Instance and Subnet security respectively). Best Practices Amazon strongly recommends (and I completely agree) that the root/master account should not be used for anything other than administering the Amazon account and creating administrative accounts. Thereafter you should be logged in as a named user (if the master account is a company account) with the minimum required privileges to do your job. With great power comes great responsibility, and its quite easy with AWS to inadvertently terminate the wrong instance (thus bringing a production server offline) or incorrectly route traffic to the wrong subnet for example. Therefore you should take the time to scope out what level of access each user requires, what functions they need to be able to perform to do their job and then match this up with the IAM policy generation tools. Amazon have done a fantastic job of giving granular access to the services and its contained functions – to the point where you can permit a user to reboot a server but not terminate it, or retrieve content from S3 but not upload (or vice-versa).Thus, as part of your getting started with IAM you should navigate to the IAM section of AWS and set up user(s) pertaining to the role they need to perform Another best practice is that if a user does not need API access, do not generate the key(s) necessary to enable it. Sure, they’re inherently obscure but why risk it? Oddly enough Amazon defaults the ‘Generate and access key for each user’ checkbox to ticked, so unless you explicitly disable this they will be created. Conversely, if a user ONLY needs API access and doesn’t need to access the console, then do not generate an IAM password that would allow them to log in to the AWS console. By default new accounts do not have a login password, and thus you control who has access to the AWS console. As with all security in IT, the least required privileges, the better! IAM roles are a relatively new addition to the IAM offering. Roles allow you to assign effective permissions to a particular role as you would a user or group, but assign this to an EC2 instance. Why would you do this? Well, prior to roles, developers would have to embed API keys & secrets in their code or user-data (or use some other mechanism for getting credentials onto an instance) in order to permit it to access another AWS service...
Read More »
Posted by lee jones on Nov 26, 2013 in Azure, Cloud
As windows Azure continues to grow from a new PaaS offering to a fully features IaaS platform, the range of services on offer continues to grow. With this in mind it is becoming increasingly difficult to differentiate between the different ways of hosting your code in Azure. This post outlines the four different options at the time of writing, two of which comprise the Azure cloud service offering and the other two remain standalone services. In order to understand these, two key concepts need to be defined: PaaS Platform as a Service = Provides a layer of abstraction in a cloud environment whereby the consumer need only worry about the code, configuration and deployment. The provider (in this case Azure) managed and maintains the network, servers, security and storage. Iaas Infrastructure as a Service = The rawest and most basic form of cloud computing, IaaS provides access to physical or more commonly virtual hardware in the form of Virtual Machines. Once provisioned, the VM and its underlying operating system remain the responsibility of the customer. All facets of its operation including storage, security, maintenance and monitoring are handled by the customer. This provides excellent control but with it a much higher maintenance burden. The main Azure code hosting choices are: Web Role (Cloud Service) A web role allows you to host your code inside an Azure cloud service meaning your site can scale to almost any size very, very easily. When Web roles are employed alongside worker roles and other services such as Azure Service Bus, they offer the most complete means of building modern cloud architectures on the Microsoft stack. Worker Role (Cloud Service) Worker Roles are headless servers that perform continuous processing without ever surfacing a front end. Typical scenarios for worker roles include processing data from service calls, processing messages off a queue or perform other blocking executions that you wouldn’t want tying up your front end. In both web and worker roles the Azure platform will still manage the underlying operating system on your behalf, but the code needs to be aware that this is happening and provision for scenarios where such maintenance may take an instance offline. Unlike Azure Websites (see below) this isn’t taken care of automatically. Web Site(s) Azure websites is the newest PaaS offering that offers a ‘fully managed’ VM environment. The Azure platform manages and maintains the underlying operating system, installing updates and performing routine maintenance meaning you only need be concerned with your code and not the platform. The platform also manages the migration of your site from one host to another so that if the underlying host fails or is recycled for maintenance, no downtime is witnessed and no data is lost. Web Sites offer a range of hosted languages including the full .net stack, PHP and Node Virtual Machines The VM offering gives the ultimate control –...
Read More »
Posted by lee jones on Sep 22, 2013 in AWS
Amazon, being the kind-hearted souls that they are allow you five static/fixed IP addresses completely free. Gratis. No charge. Nada. This is handy if, like me, you often play with EC2 isntances but only power them up when you need them, but still want to reference them at the same address each time. Normally, AWS assigns a new public DNS and private IP/DNS to each instance meaning it can be hard to reference a particular machine externally (think config files or even RDP stored credentials). Luckily, Amazon have made it trivially easy to get a fixed IP address To allocate a new IP address to an already running EC2 instance, perform the following steps: Log in to your AWS account and go to the EC2 services panel Under network & security select Elastic IPs Click Allocate New Address in the command bar Select EC2 from the drop down in the resultant popup box Right-click on the new IP address and click associate (alternatively you can use the Associate Address button in the command bar Select your EC2 instance in the resultant popup and click Yes, Associate You can now refer to that instance using a fixed IP address and not have to worry about its public DNS or private IP address changing. It’s worth noting that these addresses are free only when they are assigned to an instance. When they’re not, you will get charged a small amount, but their usefulness far outweighs the costs IMO. When you’re done with the IP, disassciate the IP address from the instance, then click the Release address button in the command...
Read More »
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.