I have a worker machine running on a spot instance with a dedicated role. I'd like to grant it the permission to run ec2-terminate-instances when it finishes but want it to be able to terminate only itself.
Couldn't find any variable of instance-id or something similar. How do I define that kind of permission?
I've also tried using shutdown -h now but the behaviour with spot instances was a bit weird - it killed the machine (terminated) but kept the spot request as fulfilled (rather than terminated-by-user)
Thanks!
Related
I've read multiple posts on running scripts on GCP VMs but unfortunately could not find an answer that would satisfy my needs.
I have a Go application and I'm looking for a way to run a bash script on a VM instance programatically.
I'm using a Google Cloud Golang SDK which allows me to fetch VM instance info. Unfortunately SDK does not contain a functionality that allows running a bash script on a specific instance(unlike an Azure Cloud SDK for example).
Options I've found:
Google Cloud Compute SDK has an option to set a startup script, that
will run every time an instance is restarted.
Add instance-level public SSH key. Establish an SSH connection and
run a script using Go SSH client.
Problems:
Obviously startup script will require an instance reboot and this is not possible in my use case.
SSH might be also problematic, in case instance is not running SSH
daemon or SSH port is not open. Also, SSH daemon config does not
permit root login by default(PermitRootLogin might be false), thus
script might be running on a non privileged user, making this option not
suitable either.
I should probably note that I am not authorised to change configuration of those VMs (for example change ssh daemon conf to permit root login), I can just use a token based authentication to access them, preferably through SDK, though other options are also possible as long as I am not exposing the instance to additional risks.
What options do I have? Is this even doable? Am I missing something?
Thanks!
As said by Kolban, there is no such API to trigger from outside a bash inside the VM. The best solution is to deploy a webserver (a REST API) that call the bash and to expose it (externally or internally).
But you can also cheat. You can create a daemon on your VM that you run with a startup script and that listen a custom metadata; let's say check it every seconds.
When the metadata is updated, the daemon can perform actions. You can imagine that the metadata contain the script to run with the parameters. At the end of the run, the metadata is cleaned by the daemon.
So now, to run your bash, call the setMetadata Api. It's not out of the box, but you can have something similar of what you expected.
Think of GCP as providing the virtual machine infrastructure such as compute, memory, disk and networking. What runs when the machine boots is between you and the machine image. I am hearing you say that you want to run a bash script within the VM. That is outside of the governance of GCP. GCP will only affect the operation and existence of the environment. If what you want to happen is run a script within the VM programatically you will need to run some form of demon inside the VM that can be signaled to run such a script. This could be a web server such as flask or express, it could be your SSH server or it could be some other technology you choose.
The core thing I think you were looking for was some GCP API that, when called, would run a script within the Compute Engine. I'm going to say that there is no such API.
I am new to AWS EC2 instance. I use ssh to connect to the instance and just want to know how to leave the instance properly. Sometimes I just close the terminal but I couldn't connect to it next time. Then I use
shutdown -h now
It works, but this way I need to restart the instance next time. Is any proper way to leave the instance?
Type
exit
if you just want to leave it and keep it running
The EC2 instance runs independently of you connecting to it. Each time you SSH in to the instance you start a new interactive shell. exit or Control-D will close the shell that you have logged in to, and leave the instance running.
If your instance is on-demand, you can shut it down to save costs, but that is an entirely separate operation from logging in and out.
I've spent 3 days beating my head against this before coming here in desperation.
So long story short I thought I'd fire up a simple PHP site to allow moderators of a gaming group I'm in the ability to start GCP servers on demand. I'm no developer so I'm looking at this from a Systems perspective to find the simplest solution to do the job.
I fired up an Ubuntu 18.04 machine on GCP and set it up with the Google SDK, authorised it for access to the project and was able to simply run gcloud commands which worked fine. Had some issues with the PHP file calling the shell script to run the same commands but with some testing I can see it's now calling the shell script no worries (it broadcasts wall "test") to console everytime I click the button on the PHP page.
However what does not happen is the execution of the gcloud command. If I manually run this shell script it starts up the instance no worries and broadcasts wall, if I click the button it broadcasts but that's it. I've set the files to have execution rights and I've even added the user nginx runs as to have sudo rights, putting sudo sh in front of the command in the PHP file also made no difference. Please find the bash script below:
#!/bin/bash
/usr/lib/google-cloud-sdk/bin/gcloud compute instances start arma3s1-prod --zone=australia-southeast1-b
wall "test"
Any help would be greatly appreciated, this coupled with an automated shut down would allow our gaming group to save money by only running the servers people want to play on.
Any more detail you want about the underlying system please let me know.
So I asked a PHP dev at work about this and in two seconds flat she pointed out the issue and now I feel stupid. In /etc/passwd the www-data user had /usr/sbin/nologin and after I fixed that running the script gcloud wanted permissions to write a log file to /var/www. Fixed those and it works fine. I'm not terribly worried about the page or even server being hacked and destroyed, I can recreate them pretty easily.
Thanks for the help though! Sometimes I think I just need to take a step back and get a set fresh of eyes on the problem.
When you launch a command while logged in, you have your account access rights to the Google cloud API but the PHP account doesn't have those.
Even if you add the www-data user to root, that won't fix the problem, maybe create some security issues but nothing more.
If you really want to do this you should create a service account and giving the json to the env variable, GOOGLE_APPLICATION_CREDENTIALS, which only have the rights on the compute instance inside your project this way your PHP should have enough rights to do what you are asking him.
Note that the issue with this method is that if you are hacked there is a change the instance hosting your PHP could be deleted too.
You could also try to make a call to prepared cloud function which will create the instance, this way, even if your instance is deleted the cloud function would still be there.
i never really understood how to start a docker and how to maintain it alive.
I have a question, so when you start a docker in the terminal you must provide a command for the docker so it maintains alive, and when you dont provide a service it restarts everytime, you can provide the /bin/bash so it maintains open. (Could you show me how to do it the right way, maintain it open with bash ?)
When it comes to rancher, when you create a new docker you can provide the command too, but if you dont the docker won't restart it maintains alive, so what does this means, that it have default command ? (/bin/bash)? What command does exactly executes rancher to start the docker?
thank you all
It is probably best if you read some about docker, to get the various concepts clear. From your use of "a docker", it seems that you don't really have all the pieces yet for an easy understanding.
A quick layout would be that you have
Image. I have seen this compared to a 'class' in programming
Container. In the same comparison, this would be an object: an instance of a class.
If you want to run something with docker, you start a container from an image. Just like if you want to create an object, you create one from a class. (lets not take this comparison/simili too far)
Now a containers purpose is to run something, rather, to run a single something. So "keeping a docker open" is not something you 'should want' What you want is to run, for instance, a server. Or a script.
Every container runs a single process (or should run one). As the 'official' usecase is not 'create a virtual server you can play around', it might behave strange or complicated if you want to have place to ssh to and not run a specific thing.
This also means you don't want to run any services as a background: if you run apache, you want to run it not as a daemon, but just run it: that's what the docker container is for. If you need to run something else (for instance, a database server) you would start a second container.
There might be exceptions for this, but to get your head around the why stuff works as it does, you should probably start somewhat religiously with these 'rules', and from that point go on.
I want a single script that can lauch, and tag my instances which I can then use chef to configure them accordingly.
Say my service requires 10 instances, I want to be able to run 10 instances, then tag them according to their role (web, db, app server).
Then once I do that, I can use chef to connect to each one and configure them how i want.
But I'm confused, I know I can launch instances, but how do you wait for them to come online? Do you have to continously loop in some sort of a timer? That seems like a very hacky way to do it!
If you're going to do everything from the outside you do just have to poll to wait for the instance to be ready (which doesn't necessarily mean its ready to use - actual startup completed a little later)
You can also pass user data when you start an instance. Most amis support cloud init, and will interpret the data passed as a shell script if in the right format. That shell script could run chef or do other configuration tasks.