I am trying the Alibaba Cloud, ECS instances and after doing some configuration I would like to persist that so that if I want to rollback the Instance after certain period I can start from the last checkpoint. What I want to understand is if Taking a SnapShot/Image on Free trial would cost me money ? or in other words if I create an image or snapshot would that be chargeable, if yes then how much would it cost to me for each snap shot or image?
Best Regards
As per the mentioned terms while creating image -
When you create an image, a snapshot will be created as well. Because
the snapshot service is now a paid service, your images will incur
snapshot fees.
When creating a custom image with Linux system, please
do not load data disk information in the /etc/fstab file. Otherwise,
you cannot launch the instance created through the image.
You can create a complete image template for the current ECS instance,
including all its disks. A new snapshot will be taken for each
instance disk and can be viewed in the snapshot list. You must wait
for the snapshots for each disk to be created before the image can be
used. Please be patient.
So yes taking snap shot or creating image has cost associated with it, how much cost is dependent on how much resources has been associated with it. Please refer to below screenshot for the reference -
As per the official documentation, snapshots service is free of charge. You can reaffirm this with the following figure of their documentation.
Related
I have a golden image pipeline running without problem backed by an EBS volume, but trying to create the same for an instance store backed ami seems to always produce the same error. The issue is that the imagebuilder pipeline continuously attempts to tag a non-existent EBS volume and therefore fails;
Reason for failure:
You cannot specify tags for EBS volumes if there are no EBS volumes being created by the request.
The base image is ami-08d82c356d670cf9c which has the root device type INSTANCE-STORE, and there are no tags applied anywhere in the pipeline (not in the configuration, distribution, recipe or infrastructure). There is little documentation regarding a golden image using instance storage and any attempt to create one results in the same failure.
Does anyone have an idea on where this application of tags is taking place in the process in order to avoid it?
Thanks
Confirmed with AWS that Image Builder does not support the use of AMIs backed by instance store, as they use ec2:CreateImage which does not support it, and also requires the instance to be shut down to create an image.
I have a spring-boot application running on a container. One of the APIs is a file upload API and every time a file is uploaded it has to be scanned for viruses. We have uvscan to scan the uploaded file. I'm looking at adding uvscan to the base image but the virus definitions need to be updated on a daily basis. I've created a script to update the virus definitions. The simplest way currently is to run a cron inside the container which invokes the script. Is there any other alternative to do this? Can the uvscan utility be isolated from the app pod and invoked from the application?
There are many ways to solve the problem. I hope, I can help you to find what suits you best.
From my perspective, it would be pretty convenient to have a CronJob that builds and pushes the new docker image with uvscan and the updated virus definition database on a daily basis.
In your file processing sequence you can create a scan Job using Kubernetes API, and provide it access to shared volume with a file you need to scan.
Scan Job will use :latest image, and if new images will appear in the registry it will download new image and create pod from it.
The downside is when you create images daily it consumes "some" amount of disk space, so you may need to invent the process of removing the old images from the registry and from the docker cache on each node of Kubernetes cluster.
Alternatively, you can put AV database on a shared volume or using Mount Propagation and update it independently of pods. If uvscan opens AV database in read-only mode it should be possible.
On the other hand it usually takes time to load virus definition into the memory, so it might be better to run virus scan as a Deployment than as a Job with a daily restart after new image was pushed to the registry.
At my place of work, we also run our dockerized services within EC2 instances. If you only need to update the definitions once a day, I would recommend utilizing an AWS Lamda function. It's relatively affordable and you don't need to worry about the overhead of a scheduler, etc. If you need help setting up the Lambda, I could always provide more context. Nevertheless, I'm only offering another solution for you in the AWS realm of things.
So basically I simply added a cron to the application running inside the container to update the virus definitions.
I accidentally took snapshot from volume (100GB) that was attached to running instance (as a ROOT device). The snapshot creation took over one hour! After that I created bigger (400GB) volume from that snapshot and everything went fine. Then I:
stopped the instance
detached the old 100GB device from my instance
attached the new 400GB volume to that instance
started the instance
Everything seemed OK in AWS control panel (server running and disk status was fine) but I could not connect to that instance via SSH nor HTTP. SSH error: connection refused. So I changed back to old 100GB disk and instance worked well.
My suggestion was that something went wrong because of taking snapshot from running instance. So I deleted the snapshot and took new snapshot from stopped instance (volume). This time the creation of snapshot took only 5 minutes. Then I just created new volume from that snapshot, attached it to instance and started.. still not working.
So my questions are:
Can it be possible that even when I delete the old snapshot the data of that snapshot was partially used when making new snapshot?
How can I backup my current volume if every time I take a snapshot it uses old corrupted data
All these things were done via AWS control panel.
THANKS!!
Can it be possible that even when I delete the old snapshot the data
of that snapshot was partially used when making new snapshot?
I don't think so. It could be that when you created the first snapshot there were some resources in contention when trying to create it. Thus it took longer. Amazon is not clear about all the resources that they are using under the hood. In a way is good and bad. Good because it takes away most complexities and bad well because you can't see what the hell is going on.
How can I backup my current volume if every time I take a snapshot it
uses old corrupted data
You can either stop your instance before taking the volume snapshot or you can just create an AMI (Image) with making sure that the no reboot option is not checked.
See below:
Hi i had created a ubuntu cloud instance for about 8Gb.Now i require to increase the size to say 32Gb.Any idea how to proceed will be much helpful.
If you do not care about downtime, you can take a snapshot from your EBS volume and create a new volume from this, specifying a larger EBS size and attaching it to another instance. Keep in mind that you may have to enlarge your file system on it, too.
A detailed description of this can be found here.
I am running a vanilla Windows install on Amazon EBS volume. The computer takes 10 minutes to boot, which may be understandable as 2 reboots are required. However, taking a snapshot is also a 10-15 minute process. Can anyone explain this? Any way to speed it up? I am a bit surprised, because I thought that snapshots are immediate replicas of the running EBS volume, in which case shouldn't they take just a couple of seconds to complete?
I will add that the console shows that "snapshot" is completed very quickly. But the "AMI" section is what seems to take 10-20 minutes. What's the difference? Is the snapshot available for use immediately, or do I need to wait for the AMI?
From the EBS product page:
Amazon EBS snapshots are incremental
backups, meaning that only the blocks
on the device that have changed since
your last snapshot will be saved. If
you have a device with 100 GBs of
data, but only 5 GBs of data has
changed since your last snapshot, only
the 5 additional GBs of snapshot data
will be stored back to Amazon S3.
Subsequent snapshots are fast because only the changed blocks need to be saved. So the time it takes scales with the amount of changes since the last snapshot.
Is the snapshot available for use
immediately, or do I need to wait for
the AMI?
Also from the product page:
New volumes created from existing
Amazon S3 snapshots load lazily in the
background. This means that once a
volume is created from a snapshot,
there is no need to wait for all of
the data to transfer from Amazon S3 to
your Amazon EBS volume before your
attached instance can start accessing
the volume and all of its data. If
your instance accesses a piece of data
which hasn’t yet been loaded, the
volume will immediately download the
requested data from Amazon S3, and
then will continue loading the rest of
the volume’s data in the background.
The creation of an AMI is a multiple-step process.
The Snapshot of the current machine is started (that's darn near instantaneous)
The snapshot copies the "changed blocks" from the base AMI to the snapshot lazily (that's pretty quick too)
The underlying Windows image is then prepared to be an AMI base image this starts with booting a "ghost" instance from the image with the snapshot as the disk image.
A SYSPREP is started to "reseal" the machine so it gets new machine SIDs.
The new image is then re-snapshotted
The AMI is marked "complete"