Assuming a cloud infrastructure across multiple cloud provider accounts (AWS, Azure and GC) built with Terraform. Is there any way to reboot instances using Terraform? If not, how do people easily and centrally reboot their instances created with Terraform?
Thanks!
Terraform does not provide capacity to reboot your instances. At best, you could taint a resource, that means that terraform will destroy and recreate (which is obviously not the same the rebooting). Terraform is not the right tool to manage the lifecycle of your instance.
Usually, the best practice is to get your instance automatically rebooted, using cloudwatch on AWS. You need to configure it to detect unhealthy instances. I guess other cloud providers have a similar feature.
If you need to do it manually, next step would be to use the cloud API (such as aws cli) to perform this action. I am not aware of a tool that let you do that across cloud providers centrally.
Related
Given that I have a 24x7 AKS Cluster on AZURE, for which afaik Kubernetes cannot stop/pause a pod and then resume it standardly,
with, in my case, a small Container in a Pod, and for that Pod it can be sidelined via --replicas=0,
then, how can I, on-demand, best kick off a LINIX script packaged in that Pod/Container which may be not running,
from an AZURE Web App?
I thought using ssh should work, after first upscaling the pod to 1 replica. Is this correct?
I am curious if there are simple http calls in AZURE to do this. I see CLI and Powershell to start/stop AKS cluster, but that is different of course.
You can interact remotely with AKS by different methods. The key here is to use the control plane API to deploy your kubernetes resource programmatically (https://kubernetes.io/docs/concepts/overview/kubernetes-api/) .
In order to do that, you should use client libraries that enable that kind of access. Many examples can be found here for different programming languages:
https://github.com/kubernetes-client
ssh is not really recommended since that is sort of a god access to the cluster and its usage is not meant for your purpose.
I 'm using many services in Alibaba Cloud like Container Service, VPC, RDS, DNS, OSS and many more.
Instead of importing 1 by 1 of Alibaba Cloud Product Services that used that would take a long time for that.
Is there any elegant and fast way to importing all of the cloud infrastructure to a statefile ?
Yes, you can make a resource list and then run terraform but make sure you can have
We have a number of Service Fabric clusters provisioned in Azure, for dev and testing. I would like to find a way to 'pause' these over night to save paying for them when they're not being used.
This seems to be what the Azure Dev Labs are for, but as far as I can see they don't support Service Fabric Clusters.
I'm thinking of writing a script to completely tear these environments down at night and rebuild them in the morning, but before doing that I'm wondering if there are any better ways.
Service Fabric clusters cannot be safely "paused". If you shut down all VMs, there is a chance that the cluster's state - the applications and their data - will be lost.
If you don't mind starting with a fresh set of clusters every morning, it's pretty straightforward to automate. You can define your environments using ARM templates and write a short script to provision, then create another script to delete the resource groups at the end of the day, which will remove the VMs and all associated resources.
My understanding of the VMs involved in Azure Cloud Services is that at least some parts of it are not meant to persist throughout the lifetime of the service (unlike regular VMs that you can create through Azure).
This is why you must use Startup Tasks in your ServiceDefinition.csdef file in order to configure certain things.
However, after playing around with it for a while, I can't figure out what does and does not persist.
For instance, I installed an ISAPI filter into IIS by logging into remote desktop. That seems to have persisted across deployments and even a reimaging.
Is there a list somewhere of what does and does not persist and when that persistence will end (what triggers the clearing of it)?
See http://blogs.msdn.com/b/kwill/archive/2012/10/05/windows-azure-disk-partition-preservation.aspx for information about what is preserved on an Azure PaaS VM in different scenarios.
In short, the only things that will truly persist are things packaged in your cscfg/cspkg (ie. startup tasks). Anything else done at runtime or via RDP will eventually be removed.
See - How to: Update a cloud service role or deployment - in most cases, an UPDATE to an existing deployment will preserve local data while updating the application code for your cloud service.
Be aware that if you change the size of a role (that is, the size of a virtual machine that hosts a role instance) or the number of roles, each role instance (virtual machine) must be re-imaged, and any local data will be lost.
Also if you use the standard deployment practice of creating a new deployment in the staging slot and then swapping the VIP, you will also lose all local data (these are new VMs).
I've got my head around creating cloud instances in AWS, Azure and Rackspace. However, I need to turn my instances off at the end of the day and on in the morning as this will half my hosting cost (they are for development).
I've looked at a few management services but they blew my brains out. Is there a simple way to do this?
Azure
REST:
You can do this to Azure deployments by using the Windows Azure Service Management REST API. Because it is REST you can use most programming languages to access it.
You could have an application running on your local machine that schedules calls to these services to delete at a certain time at the end of office hours and then create your service again in the morning.
PowerShell:
Or you can manage your deployments in the same way but instead of using REST you can use Azure PowerShell cmdlets. I have done this way myself and it works nicely.
To help you get started there is a nice tutorial on how to do use PowerShell to deploy Azure applications.
also if you didn't already know I should also mention there is a 3month free trial with Azure if you are simply looking for cutting costs whilst developing.
Approach
You could always roll your own solution, insofar most cloud providers offer a respective API to start/stop instances on demand (or even on schedule), which is what those management services are actually using as well of course - the AmazonEC2 Java interface offers all relevant methods for example (amongst many others), specifically:
StartInstances()
StopInstances()
RebootInstances()
Via Scripting (EC2)
The most simple approach for this regarding Amazon EC2 would be to craft yourself some Python scripts by means of the excellent boto (An integrated interface to current and future infrastructural services offered by Amazon Web Services), which exposes all EC2 methods mentioned above; you could then start those scripts on demand or via your operating system scheduler.
Via Continuous Integration / Automation (EC2)
Another option would be to facilitate a continuous integration server as an automation engine (a sometimes overlooked aspect of these systems), in case you happen to run one anyway; it would allow you to both start/stop instances on demand or scheduled similar to cron.
We do exactly this by means of the Bamboo AWS Plugin (it's Open Source and the code is available on Bitbucket), see my answer to How to start and stop an Amazon EC2 instance programmatically in java for more details on this approach. While Atlassian Bamboo is a commercial offering, there should be something similar available for popular Open Source CI solutions like e.g. Jenkins as well.
NOTE: As for June of 2013, IaaS Instances can be placed in a "stopped (deallocated)" state. In this state you are only billed for storage of any disks associated with the VM. The original answer below describes a VM instance that is in a "stopped" but not deallocated state. The deallocated state is currently the default for VM stop actions taken via the Azure management portal.
The only way to accomplish this in Widows Azure today is to delete the deployment.
If you stop the service, you are still billed (like renting office space, you pay for it even if you aren't in it), and you can't set the instance count to zero. An option may use is to just reduce the instance count to absolute minimum (1) an then scale it back up during needed hours. But the cost benefits of this will depend on the size of your instances.
Old thread I know, but Microsoft introduced 'Runbooks' for Azure in 2014 that you can use for automation, including scheduled startups and shutdowns. As mentioned above, be sure you are in stopped (deallocated) state, as opposed to just stopped, in order to prevent charges.
More info:
Script to stop your VMs
Azure automation, official MS docs.
Yes Automation Runbook are there by which we can schedule the job. I created the script for stopping (De-allocated) Azure VM.
https://gallery.technet.microsoft.com/Deallocate-all-VM-under-79049c69
Please read about how to use runbook http://azure.microsoft.com/blog/2014/06/19/azure-automation-runbook-management/
Dellocation and stop are different, since stop vm will also incur cost.
The best article on automation + switching on/off VMs I have found so far. [05 February 2015]. http://clemmblog.azurewebsites.net/using-azure-automation-start-und-stop-virtual-machines-schedule/
Recommended solution for AWS:
The AWS Data Pipeline is uniquely suited to this task. Data Pipeline
uses AWS technologies and can be configured to run AWS CLI commands on
a set schedule with no external dependencies. Data Pipeline can write
logs to S3 and runs in the context of an IAM role, which eliminates
key management requirements. Data Pipeline is also cost effective; for
example, the Data Pipeline free tier can be used to stop and start
instances once per day.
https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-ec2-instances/
Refer to this article, there some options to turn your instances on/off inside AWS.
AWS Datapipeline
AWS Lambda scheduled events
Scheduled Cron on EC2 instance
Scheduled Scaling of Auto Scaling Group
So in your case I'd recommend the followings:
For AWS:
Through Shell Command like AWS CLI commands: See Turn on/off
Cloud instances using AWS Pipeline. this method will initiate a
separate EC2 instance to be started and terminated for each AWS API
call that running times affect to your Bill.
Through programming languages like Node.js / Python: See Turn
on/off Cloud instances using AWS Lambda. The task running twice a
day for typically less than 3 seconds with memory consumption up to
128MB typically costs less than $0.0004 USD/month
For Azure and Rackspace (or other platforms you may have):
Use the above tools to provide a Respective API to start/stop instances on demand.
You may also consider to set scripts-per-boot which runs each time your instance is started.
AWS
AWS SDK is your best bet but I am using TotalCloud.io to start and stop instances under the free tier. Very customizable.
Easy to setup.