appc / spec

App Container Specification and Tooling (archived, see https://github.com/rkt/rkt/issues/4024)
Apache License 2.0
1.26k stars 146 forks source link

Outline architectural decisions (ARCHITECTURE.md?) #379

Open globalcitizen opened 9 years ago

globalcitizen commented 9 years ago

Purely IP, linux and LXC-oriented (pod definition explicitly references a subset of linux kernel namespaces), with additional environment and security posture assumptions:

jonboulle commented 9 years ago

The reference to Linux namespaces is illustrative, not prescriptive, I just changed the wording on that to try make that clearer. I think if we try to describe things like the pod execution environment without referencing (as examples, not prescriptions) actual technologies it's going to be impossibly vague.

On Wed, May 6, 2015 at 9:23 AM, Walter Stanish notifications@github.com wrote:

  • "Each app in a pod will start chrooted into its own unique read-write rootfs before execution."

chroot is far from Linux specific, but I am definitely sympathetic to phrasing this differently, perhaps "each app needs to be started within its root filesystem, with all entries in the filesystem available at their absolute paths. For example, on POSIX systems, this could be accomplished via the chroot system call" or something

  • "A Pod must have a layer 3 (commonly called the IP layer) network interface [...] with an IPv4/IPv6 address that is reachable from other pods."

are you really suggesting we need to be more agnostic than IP?! what would you propose?

  • stderr/stdout logging

Yeah I am not happy with how this is mentioned currently, we should tweak

  • "Network limits MUST NOT apply to localhost communication between apps in a pod." (ie. there is apparently limited support for shielding containers from one another within pods)

I am not sure what you're asking for here. Apps within a pod are by and large intended to be cooperative, I have no idea how this is a "security posture"...

globalcitizen commented 9 years ago

What I mean is you should be up-front about the scope and limits of your spec effort.

If it's Linux only, say it up front.

If it demands IP connectivity from all guests, say it up front. It's perfectly valid and in fact frequently desirable (eg. for security purposes) to run a container with no networking normally, so that choice is potentially significant to your audience.

These are simply factors of your design that need additional, clear explanation before demanding potential users sink time reading the nitty gritty specifics.