New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add draft component architecture doc #34629

Closed
wants to merge 3 commits into
base: master
from

Conversation

@cpuguy83
Copy link
Contributor

cpuguy83 commented Aug 24, 2017

Adds basic architecture details for componentization work, and some
starter protobuf definitions to work from.

This doc is still in draft form and should be considered as such even
after merge until the document states otherwise.
The intent of this commit is not to put something in the repo that is
gospel for the componentization work, but rather get the work kicked off
so a larger group can start taking a look, requesting changes, etc.

Basically, at this point this document should change or be validated by
implementation (though realistically, the document is not complete).
Over time there should be fewer changes and this would be the source of
truth for implementing a moby component.

ping @moby/moby-maintainers

@cpuguy83 cpuguy83 requested review from dnephin and tianon as code owners Aug 24, 2017

@cpuguy83 cpuguy83 force-pushed the cpuguy83:moby_components branch 2 times, most recently from d47da47 to 37fea21 Aug 24, 2017


#### Image Management

- moby-layer-store - Storage for image layers

This comment has been minimized.

@dmcgowan

dmcgowan Aug 24, 2017

Member

Is there a motivation for having this be a separate component? We want this part of the code to be deprecated by containerd and only have containerd implement the image store interface for doing image management. The implementations themselves will already have sub-components but does that make it a "moby component"?

This comment has been minimized.

@cpuguy83

cpuguy83 Aug 25, 2017

Contributor

So this wouldn't be the literal layer store that's currently in moby/moby.

This may not be a component by itself, but rather part of one (a component may comprise of more than 1 service). But it's something we need to implement.
What will actually be in here I'm not sure yet, but we need to support the existing drivers (even if re-written to be snapshotters) at least.

- MAY expose a separate API for external consumption
- SHOULD use GRPC to publish component-level services
- SHOULD be easily deployed as a container (the primary packaging format for
Moby Core, see [Packaging](#Packaging)).

This comment has been minimized.

@aaronlehmann

aaronlehmann Aug 26, 2017

Contributor

How many processes do you expect will be involved in providing functionality equivalent to Docker?

If components are separate Go binaries running in their own containers, they will be relatively heavyweight, in terms of size and memory footprint. If covering the Docker feature set involves, say, 10 binaries of 30 MB each, that may be a nonstarter for certain embedded applications. I could also see it being an issue for memory-limited VMs, especially in the cloud. If we are inefficient with resources it could push people away from containerization, or towards more bare-bones solutions like standalone containerd.

This comment has been minimized.

@cpuguy83

cpuguy83 Aug 27, 2017

Contributor

I agree this is something we'll need to watch out for.
However I would prefer to optimize for this later and I don't think it's strictly an architecture problem.

dockerd itself is only 33M, so I expect components to come in quite a bit smaller. I know GRPC brings a hefty price tag in that regard (around 10MB last I saw), though.

This comment has been minimized.

@stevvooe

stevvooe Sep 1, 2017

Contributor

GRPC brings a hefty price tag in that regard (around 10MB last I saw)

Wow. We should file that as a bug. I noticed that we are taking on way too many dependencies to carry pre-http2 Go versions. I'll bring that up at the community meeting.

@cpuguy83 cpuguy83 force-pushed the cpuguy83:moby_components branch from 37fea21 to 6500403 Aug 28, 2017

Add moby component architecture doc
Adds basic architecture details for componentization work, and some
starter protobuf definitions to work from.

This doc is still in draft form and should be considered as such even
after merge until the document states otherwise.
The intent of this commit is not to put something in the repo that is
gospel for the componentization work, but rather get the work kicked off
so a larger group can start taking a look, requesting changes, etc.

Basically, at this point this document should change or be validated by
implementation (though realistically, the document is not complete).
Over time there should be fewer changes and this would be the source of
truth for implementing a moby component.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>

@cpuguy83 cpuguy83 force-pushed the cpuguy83:moby_components branch from 6500403 to 07fd9cf Aug 28, 2017

cpuguy83 added some commits Aug 24, 2017

Generate pb.go files for component services.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Ignore component/ dir for unit tests
Signed-off-by: Brian Goff <cpuguy83@gmail.com>

@cpuguy83 cpuguy83 force-pushed the cpuguy83:moby_components branch from 07fd9cf to c528d9a Aug 28, 2017

// Metrics provides support for publishing prometheus style metrics on a GRPC endpoint.
// This would be used by a client to collect metrics and expose to an external service.
service Metrics {
rpc CollectMetrics(CollectMetricsRequest) returns (CollectMetricsResponse);

This comment has been minimized.

@stevvooe
import "github.com/moby/moby/components/api/types/container/container.proto";
import "github.com/moby/moby/components/api/types/file.proto";

service RootfsService {

This comment has been minimized.

@AkihiroSuda

AkihiroSuda Sep 26, 2017

Member

Can we just drop this service and expose bare containerd snapshotter service?
https://github.com/containerd/containerd/blob/master/api/services/snapshot/v1/snapshots.proto

That would deduplicate much effort for image&snapshot&rootfs abstraction.

cc @stevvooe @dmcgowan

This comment has been minimized.

@cpuguy83

cpuguy83 Sep 29, 2017

Contributor

Mostly this is for compatibility for abstracting docker v1 compatibility into a nice service that's not dependent on the backend implementation.
We could expose the bare containerd service and just say "moby is built on containerd end of story".

import "github.com/moby/moby/components/api/types/container/container.proto";
import "google/protobuf/duration.proto";

service ContainerRuntimeService {

This comment has been minimized.

@AkihiroSuda

AkihiroSuda Sep 26, 2017

Member

Similarly, can we just expose (almost) bare containerd service? (with some labels and extensions)
https://github.com/containerd/containerd/blob/master/api/services/containers/v1/containers.proto

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Jun 7, 2018

Let's close this for now, but we can continue the discussion

/cc @crosbymichael @dhiltgen

@thaJeztah thaJeztah closed this Jun 7, 2018

@thaJeztah thaJeztah removed this from backlog in maintainers-session Jun 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment