initial project setup #16
Conversation
updater/Dockerfile
Outdated
| COPY . /volume | ||
| RUN cargo build --locked --release --target x86_64-unknown-linux-musl | ||
|
|
||
| FROM alpine |
There was a problem hiding this comment.
Why Alpine? Why not scratch?
There was a problem hiding this comment.
We need a Linux to run the binary. There are no requirements of the Linux, I was looking for something small. What is the best choice?
There was a problem hiding this comment.
Do we need a Linux userland? It looks like we're building a statically-linked binary, which can run in a scratch container. In the Kubernetes update operator this is what we do.
If we do need a Linux userland for some reason, the other container images we vend use Amazon Linux.
There was a problem hiding this comment.
OK, I didn't realize scratch could run binaries. I'll change it to that, seems like it should work.
There was a problem hiding this comment.
Why Alpine? Why not scratch?
Fixed in a01376f
webern
requested review from
etungsten,
samuelkarp and
jahkeup
and removed request for
etungsten
In this commit we set up the basic project structure. - An integ crate that will serve as our driver for integration testing. Eventually this will be used to set up and run Bottlerocket instances that the updater can be tested against. - The updater crate. This will become the binary that checks and updates Bottlerocket instances. - A simple Dockerfile and Makefile, since we will be deploying the updater to Fargate. updater has a lib.rs file so that we can re-use some code from updater in integ, and so that updater can have a useful tests directory.
Issue number:
Beginning of work on #1.
Description of changes:
We decided that #15 was too much of a code dump. We will instead provide several PRs that get us to that state, such that the diff of each PR is a smaller diff. This is the first such PR.
Testing done:
cargo testworks in both theintegandupdaterdirectories.make imageworks at the root of the project.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.