Im trying to install Velero in a Kubernetes cluster on GCP, I have successfully installed it the first time but every time I logged back to the GCP shell the command is not available anymore, (as if the installation disappeared), I still can see my velero backups tho when I install it again
How can I persistently install any utility?
Bear in mind that Cloud Shell VM is ephemeral and is turned down when you are not using it interactively. See the documentation below:
The virtual machine instance that backs your Cloud Shell session is
not permanently allocated to a Cloud Shell session and terminates if
the session is inactive for an hour. After the instance is terminated,
any modifications that you made to it outside your $HOME are lost.
Also, I am not sure how exactly you have installed Valero in your GCP cluster but you might find this guide useful. It shows how to install Velero with HELM in GCP, step by step.
Related
When I try to install an apt package in the Cloud Shell, I install it and it works fine. Next time I open the Cloud Shell, it is not there. How do I fix this issue?
According to the Cloud Shell documentation:
When you start Cloud Shell, it provisions a Compute Engine virtual machine running a Debian-based Linux operating system. Cloud Shell instances are provisioned on a per-user, per-session basis. The instance persists while your Cloud Shell session is active; after an hour of inactivity, your session terminates and its VM is discarded. For more information about those limitations you can check the Cloud Shell usage limits.
This means that Cloud Shell is only intended to interact with the Google Cloud Platform on a temporary basis during a limited time.
In case you want to configure a shell environment the right product to use would be a Compute Engine instance. Here is a quickstart that shows how to create a Linux virtual machine (VM) instance in Compute Engine.
While a Cloud Shell environment is ephemeral (i.e., it gets torn down after session end), your Cloud Shell home directory is persistent. You can add a customization script to your home directory to reconfigure your environment when Cloud Shell starts.
I am beginning to install hadoop on a cluster. I have ssh access to these machines and I have already installed fabric on them. I was wondering if someone has already written a fabfile to install and deploy hadoop to a cluster easily.
I found this project [0]; but this is written for deploying over AWS instances. I was looking for something where I can just fill in the IPs of my machines and then execute a set of fab commands to bring up the cluster.
[0] http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide/#ec2-deployment-with-fabric-script
I'm AlexJF, the author of the scripts you linked.
The scripts you reference can also be used outside EC2. You just need to configure, as you requested, the list of hosts and configurations on the top of the fabfile.py. Be sure to set EC2 = False (which just happens to be the default).
You'll then have several useful commands available to you.
I want to run some scripts to run at the boot of the instance (server by node, and a redis database).
Since Amazon AMI is based on debian, I thought I could use update-rc.d to manage scripts.
Hwoever, when I type update-rc.d it says the command is not found.
What is the correct way of adding a service to the init script?
I know about CloudFront, but that is for the case when one wants to start up the instance for the first time and install some basic programs, right? For my case, I just want my instance to run some programs when it starts running from the reboot.
The image that I am using is amzn-ami-2011.09.2.x86_64.ext4.
As I want to install Jenkins (ex-Hudson) to operate my continuous integration processes on AWS Beanstalk, I need a custom AMI because some parameters in Tomcat & Linux have to be changed for Jenkins
I run the process of installing and customizing the instance started initially by Beanstalk until the end and Jenkins works like a charm on it.
But, what I can't do is reuse the AMI that I generated at the end of my customization: the health check done by BeansTalk doesn't see the EC2 instance although Beanstalk started it and it works fine.
In order to understand my issue, I reduced my failing process to the following:
a) I create a new BT application / environment based on sample provided by Amazon (only parameter that I had is a keypair to SSH my EC2 instance)
b) when the EC2 instance is started, I use the EC2 to flash the AMI
c) I modify the BT env config by changing the original AWS Ami (id: 100fff79 - Tomcat 6 64 bits) by the 1 that I genrated in (b)
d) the BT rebuilds when I change the ami id
e) the rebuild restarts the EC2 instance.
f) It starts fine (can ssh to it) but the health checking fails and my env turns to red status.
Can somebody replicate this process and tell me what I am doing wrong ?
(I would like to use the AMI of (b) as starting point for my Jenkins customization.?
Additional info that I can provide:
when ssh-ing to the EC2 instance, a grep for apache, java, thin & bluepilld as described at bottom of https://forums.aws.amazon.com/thread.jspa?threadID=59027&tstart=25 shows that the 4 expected processes disappeared. Hence, the failure.
Please, help !
regards
didier
will answer my own question: the right way to obtain a working customized ami for Beanstalk is not to try to flash a running instance launched by Beanstalk but rather start the template ami for Beanstalk (ami-100fff79 for Tomcat 6 64 bits in my case) from EC2 console and customize it from there, flash it and you're done.
You can then "edit configuration" for your BT environment by changing the ami to the new one and it works fine.
regards
didier
If you give more details, this is a feature I'm planning for version 0.3.0 of Beanstalker, my set of Maven plugins for automating maven deployments to Elastic Beanstalk and Elastic MapReduce. It is available at http://beanstalker.ingenieux.com.br/
Actually, the placeholders are there, but I haven't still done full testing of that. Are you willing to try and give help and advice?
You should be able to create a customized AMI from a running instance as long as you delete /opt/elasticbeanstalk/srv/hostmanager/db/hostmanager.db on the instance before building the new AMI. I keep seeing people say "it can't be done, you need to start a clean instance outside of Elastic Beanstalk" and that's bunk. I've done it.
A full write-up of what I've done to customize my install is here: http://stormerider.com/blog/2012/08/16/building-an-ubuntu-ami-with-elastic-beanstalk-support/ -- some of it may not apply to you, some of it may.
I was searching for EC2 EBS storage Centos 5.4 AMI in the community AMI and eventually I found Rightscale AMI (I think they called it RightImage).
Now I have created instance using that AMI, but I found out there is some Rightscale stuff inside which is worrying me about the safety on using it. I found out there are the following files in that AMI:
/etc/init.d/rightimage
/etc/init.d/rightlink
/etc/init.d/rightscale
/home/ec2
/home/s3sync
(may be more other files I haven't found out yet)
I know I can look into the script and folder and see what they do, but since a lot of user here recommended using Rightscale Centos AMI in EC2, I hope may be there is already some gurus here know what those mentioned script and folder doing and could advice me
i)whether is it safe to delete them. (I'm more concern on whether my data in the server will be safe by using this AMI)
ii)any installed apps in RightScale AMI that should be deleted
And if you think there is other free EC2 Centos AMI that is secure and solid, do suggest as well, thanks !
In order for RightScale to properly manage instances in ec2 they use a ruby based daemon called RightLink as a communication device between their core platform and each instance that is launched. The init scripts that you saw are required for the instance to self configure itself to the point where it can be managed by RightScale properly.
/etc/init.d/rightimage is the first script that is run. Essentially it just determines the OS, arch version, and installs the correct RightLink package from the S3 bucket. Afterwards it kicks off the /opt/rightscale/bin/post_install.sh script which uses the OS init control tools to register the startup scripts to be invoked on future boots of the OS; this ensures that RightLink will always be started.
/etc/init.d/rightscale is the next script that is run. It initializes RightScale-specific (but not RightLink-specific) system state. It is responsible for caching launch settings (aka userdata) and metadata in /var/spool and installing any available patches to the RightLink agent.
/etc/init.d/rightlink is the final script that is run. It configures and enrolls the RightLink agent idempotently. If configuration and enrollment succeed, rightlink starts the sandboxed monit which starts the persistent agent process. If you're not launching the AMI using the RightScale platform this will never properly enroll because they aren't expecting it to, as such RightScale will have no communication with the instance at all.
Removing all three of these from the image shouldn't in any way harm the overall stability of the image, but from a security standpoint they shouldn't cause any problems if they are present.
If you have any further specific questions about it I'd suggest hopping on their forums at https://forums.rightscale.com/
You could also try #rightscale on freenode.