Add aws image generation based of the raw image #338
Conversation
|
This has been tested by creating a raw image from master, uploading it to s3, creating a snapshot then turning that snapshot into an ami (cos_0.5.6-recovery.raw) Then launching the packer process and deploying version 0.5.5 from the repositories snapshooting the image and manually booting from it to test that it was working. |
packer/images.json.pkr.hcl
Outdated
| provisioner "shell" { | ||
| only = ["amazon-ebs.cos"] | ||
| inline = [ | ||
| "cos-deploy --docker-image quay.io/costoolkit/releases-opensuse:cos-system-${var.cos_version}", |
There was a problem hiding this comment.
I would just leave this open as an entire variable, like container_image. In this way the template can be used to bootstrap also images from external images too
There was a problem hiding this comment.
like this? or the full url?
Thing is, we can take advantage of the cos version for several places
There was a problem hiding this comment.
I know, but this ideally should work also with custom images, not only for cOS ones, and we can't assume they are using luet for the building process. I would really let open to a cos-deploy-args even for now
There was a problem hiding this comment.
how about now?
Still, I think we are confusing things here. We are providing packer templates for our own use, to publish our images. We dont have an obligation to provide packer templates for derivatives or other customers.
We can provide examples, but those examples are not gonna be anything out of the ordinary from any example packer templates as they will use our published image as base, which is ready for consumption and then they can expand on that to build their own images following the packer documentation on how to provision stuff.
We need a clear separation here, because making OUR own stuff too flexible just in case someone uses it, only causes us identity issues. Is this for us, is this for derivatives? We should have a clear line here, this is for OUR deployment of images, here are also some examples on how to consume our images with packer.
There was a problem hiding this comment.
I thought that was clear from the card, but apparently it wasn't 😅 sorry !
The packer templates for Cloud are for derivatives/users only, as long as we don't need them internally to provide base images. The fact that we use packer to spin up images used for tests is for convenience, but it is flexible enough to be re-used for derivatives too in case of need.
We could also use raw disks for tests for example, but then we don't have a way to see if we break the installation process.
There was a problem hiding this comment.
but...wont we need to publish images to cloud providers so others can consume them? ITs a different process altogether I think. In aws, are we gonna provide derivatives a recovery image instead of a fully released image??? Doesn't seem good to me, they will need to actually install the system and then once the image is "working" deploy their stuff.. I havent seen an image that works like that in a cloud provider, they are all ready images so your first launch with user data can configure it completely.
There was a problem hiding this comment.
what we are going to publish is only vanilla images where only the recovery partition is working.
cOS is not meant to actually be used by per-se, but it's main use is to allow a complete system customization via container images. The recovery image just serves the purpose to bootstrap the minimal required to run the container image you supply (and taking later upgrades from). That can be a system/cos image (the one we use), but that could be a foo/bar image that will later on pickup upgrades from its configuration, and so on so forth
There was a problem hiding this comment.
Ok, that clarifies it a lot! Then I think down the line we may need a refactor of the templates to separate everything so it's easier for derivatives to work with! Even a readme to provide a pck.vars file by the user with the proper vars instead of cli args and some vars descriptions
packer/images.json.pkr.hcl
Outdated
| provisioner "shell" { | ||
| only = ["amazon-ebs.cos"] | ||
| inline = [ | ||
| "cos-deploy --docker-image ${var.cos_install_url}:cos-system-${var.cos_version}", |
There was a problem hiding this comment.
mmh images don't necessarly have to follow that schema, users might also pick something like myimage:testing or myimage:latest. I think we should also account that verification might be skipped as well during this process
There was a problem hiding this comment.
Thats what I though :(
Uses the new cos-deploy script to install the image from recovery and the user-data facility to partition the disk Signed-off-by: Itxaka <[email protected]>
| ssh_username = "root" | ||
| source_ami_filter { | ||
| filters = { | ||
| name = "*cos*recovery*" |
There was a problem hiding this comment.
Also probably this one too should be customizable, with a default (like this one)
Signed-off-by: David Cassany <[email protected]>
Uses the new cos-deploy script to install the image from recovery and
the user-data facility to partition the disk
As a side effect it moves from using json to using HCL for packer as json is no longer receiving any features and HCL is the recommended config language for packer
If HCL is not liked, I can easily revert to using plain json, but it had some issues on selecting the ami image using regex. HCL allows us to use "cos*recovery" and use latest to pick the latest recovery image and not have any issues with selecting the wrong image. I could not make the same work on json templates.
Fixes #302
Signed-off-by: Itxaka [email protected]