This sequence of commands works for me:
DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq
So, DEBIAN_FRONTEND=noninteractive is correct but you also need the -q flag.
Your problem is that grub file change adhere to ucf and not debconf, as per this incident on apt list you're not alone.
As workaround I found this answer on askunbuntu. Removing the menu.lst from the UCF configuration system should be enough, for your case:
"sudo ucf --purge /boot/grub/menu....
While technologically, containers and virtual machines are very different, there is no apparent difference from the perspective of your software. It seems like the argument in your question is that data is special and will always be a unique snowflake, so your question basically boils down to what to do about it in terms of DevOps, CI and Automation.
When creating an AMI, you are making a copy of your EBS volumes. This utilizes block storage and will only need to process the diffs of your EBS snapshots. If you changed a lot of data in your EBS or don't have a previous snapshot, it will take longer to create your AMI.
Here is a quote from the documentation at https://docs.aws.amazon.com/AWSEC2/latest/...
We are planning to automate this process for our Jenkins EC2 slaves.
Currently we have to manually update the AMI ID every time we build a new AMI, but by taking advantage of the config.xml file where Jenkins store all its configuration, we should be able to automatically update the AMI value in this file and then restart Jenkins to take those changes into ...
Using containers for such computation nodes makes a lot of sense, and it would offer other advantages, too. But it's not a silver bullet. You'd still have to work at it.
To really answer your question I need to know how you're deploying your system (is it with an ASG? manually? with some tool, like Ansible?).
If you're using an ASG, dockerizing it wouldn'...
You should take a look at packer, we've found it very helpful in automating builds of image types, including AMI's.
We make use of the chef client provisioner with cookbooks to manage the changes applied to an image, although many other provisioners (shell, puppet, ansible, etc) are supported. We can output docker images, AMIs and vagrant boxes from shared ...
I can answer on how we do it actually:
We're using a private Gitlab on AWS and its CI system.
We have a repository for our build environment (a docker image with packer/scripts/json describing amis) and one with a .gitlab-ci.yml which describe the build and export tasks for each of our base AMI.
Each project build its own AMI from our base one on every push ...
To add to Philipp's answer, if you are using sudo then you need to make sure to set the DEBIAN_FRONTEND variable afterwards, like so:
sudo DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq
Perhaps you might benefit from abstracting your platform (the AMI with base dependencies) from your software. Do you really need to re-roll the AMI every time you update your algorithms and models? Or, do you re-roll when you have a library change and add a deployment setup to your setup that sets up your ML stack on the AMI? If you can rework your ...
User Data Persistance
If I create an image with Packer or other tool, I'll include normally a userdata initialization script that would allow connecting via WinRM. This is required as the default AMI settings wouldn't allow the tooling to connect. In this scenario Packer would create the instance from an AMI with my provided userdata.
However, when I then ...
Is there any way to tell which AMI my EC2 instance was created from?
Short answer: yes.
Longer answer: yes - how would you like to get it?
The AMI which the EC2 instance was launched with is part of the EC2 instance metadata
Every instance publishes its metadata, which you can retrieve via the HTTP interface:
You need to create build components and define a custom installation process.
Click the 'Create Build Component' button in the 'Components' section of the 'Recipe' page. Scroll down to 'Definition' and select 'Use example' to see how it works.
The key here is the behavior of AWS AMIs in the context of ECS. By default the AWS ECS Amazon Linux AMI optimized for ECS is in charge of VOLUME management but there's a problem if you copy that AMI and try to launch a new instance -- the SECONDARY volume that ECS uses to deploy docker on can go missing.
I didn't notice any difference using -y or -q. Maybe because the question is about using "packer" ? (I use bare scripts)
Anyway, in my case, I got rid of the dialogs for apt upgrade using the following sed commands around it :
sed -i "s/#\ conf_force_conffold=YES/conf_force_conffold=YES/g" /etc/ucf.conf
apt-get -y upgrade
sed -i "s/conf_force_conffold=YES/...