{"owner":"docker","repo":"containerd","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":1093,"categories":["project-spec","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["design/architecture.md","vendor/github.com/matttproud/golang_protobuf_extensions/README.md"],"skills":{"design/architecture.md":"# Architecture\n\nTo ensure clean separation of concerns, we have organized the units of\ncontainerd's behavior into _components_. _Components_ are roughly organized\ninto _subsystems_. _Components_ that bridge subsystems may be referred to as\n_modules_. _Modules_ typically provide cross-cutting functionality, such as\npersistent storage or event distribution. Understanding these _components_ and\ntheir relationships is key to modifying and extending the system.\n\nThis document will cover very high-level interaction. For details on each\nmodule, please see the relevant design document.\n\nThe main goal of this architecture is to coordinate the creation and execution\nof _bundles_.  _Bundles_ contain configuration, metadata and root filesystem\ndata and are consumed by the _runtime_. A _bundle_ is the on-disk\nrepresentation of a runtime container. _Bundles_ are mutable and can be passed\nto other systems for modification or packed up and distributed. In practice, it\nis simply a directory on the filesystem. \n\n![Architecture](architecture.png)\n\nNote that while these architectural ideas are important to understanding the\nsystem, code layout may not reflect the exact architecture. These ideas should\nbe used as a guide for placing functionality and behavior and understanding the\nthought behind the design.\n\n## Subsystems\n\nExternal users interact with services, made available via a GRPC API.\n\n- __*Distribution*__: The distribution service supports pulling images.\n- __*Bundle*__: The bundle service allows the user to extract and pack bundles\n  from disk images.\n- __*Runtime*__: The runtime service supports the execution of _bundles_,\n  including the creation of runtime containers.\n\nTypically, each subsystem will have one or more related _controller_ components\nthat implement the behavior of the _subsystem_. The behavior of the _subsystem_\nmay be exported for access via corresponding _services_.\n\n## Modules\n\nIn addition to the subsystems have, we have several components that may cross\nsubsystem boundaries, referenced to as components. We have the following\ncomponents:\n\n- __*Executor*__: The executor implements the actual container runtime.\n- __*Supervisor*__: The supervisor monitors and reports container state.\n- __*Metadata*__: Stores metadata in a graph database. Use to store any\n  persistent references to images and bundles. Data entered into the\n  database will have schemas coordinated between components to provide access\n  to arbitrary data. Other functionality includes hooks for garbage collection\n  of on-disk resources.\n- __*Content*__: Provides access to content addressable storage. All immutable\n  content will be stored here, keyed by content hash.\n- __*Snapshot*__: Manages filesystem snapshots for container images. This is\n  analogous to the graphdriver in Docker today. Layers are unpacked into\n  snapshots.\n- __*Events*__: Supports the collection and consumption of events for providing\n  consistent, event driven behavior and auditing. Events may be replayed to\n  various _modules_\n- __*Metrics*__: Each components will export several metrics, accessible via\n  the metrics API. (We may want to promote this to a subsystem.\n\n## Data Flow\n\nAs discussed above, the concept of a _bundle_ is central to containerd. Below\nis a diagram illustrating the data flow for bundle creation.\n\n![data-flow](data-flow.png)\n\nLet's take pulling an image as a demonstrated example:\n\n1. Instruct the Distribution layer to pull a particular image. The distribution\n   layer places the image content into the _content store_. The image name and\n   root manifest pointers are registered with the metadata store.\n2. Once the image is pulled, the user can instruct the bundle controller to\n   unpack the image into a bundle. Consuming from the content store, _layers_\n   from the image are unpacked into the _snapshot_ component.\n3. When the snapshot for the rootfs of a container is ready, the _bundle\n   controller_ can use the image manifest and config to prepare the execution\n   configuration. Part of this is entering mounts into the execution config\n   from the _snapshot_ module.\n4. The prepared bundle is then passed off to the _runtime_ subsystem for\n   execution. It reads the bundle configuration to create a running container.\n\n","vendor/github.com/matttproud/golang_protobuf_extensions/README.md":"# Overview\nThis repository provides various Protocol Buffer extensions for the Go\nlanguage (golang), namely support for record length-delimited message\nstreaming.\n\n| Java                           | Go                    |\n| ------------------------------ | --------------------- |\n| MessageLite#parseDelimitedFrom | pbutil.ReadDelimited  |\n| MessageLite#writeDelimitedTo   | pbutil.WriteDelimited |\n\nBecause [Code Review 9102043](https://codereview.appspot.com/9102043/) is\ndestined to never be merged into mainline (i.e., never be promoted to formal\n[goprotobuf features](https://github.com/golang/protobuf)), this repository\nwill live here in the wild.\n\n# Documentation\nWe have [generated Go Doc documentation](http://godoc.org/github.com/matttproud/golang_protobuf_extensions/pbutil) here.\n\n# Testing\n[![Build Status](https://travis-ci.org/matttproud/golang_protobuf_extensions.png?branch=master)](https://travis-ci.org/matttproud/golang_protobuf_extensions)\n"},"files":{"design/architecture.md":"# Architecture\n\nTo ensure clean separation of concerns, we have organized the units of\ncontainerd's behavior into _components_. _Components_ are roughly organized\ninto _subsystems_. _Components_ that bridge subsystems may be referred to as\n_modules_. _Modules_ typically provide cross-cutting functionality, such as\npersistent storage or event distribution. Understanding these _components_ and\ntheir relationships is key to modifying and extending the system.\n\nThis document will cover very high-level interaction. For details on each\nmodule, please see the relevant design document.\n\nThe main goal of this architecture is to coordinate the creation and execution\nof _bundles_.  _Bundles_ contain configuration, metadata and root filesystem\ndata and are consumed by the _runtime_. A _bundle_ is the on-disk\nrepresentation of a runtime container. _Bundles_ are mutable and can be passed\nto other systems for modification or packed up and distributed. In practice, it\nis simply a directory on the filesystem. \n\n![Architecture](architecture.png)\n\nNote that while these architectural ideas are important to understanding the\nsystem, code layout may not reflect the exact architecture. These ideas should\nbe used as a guide for placing functionality and behavior and understanding the\nthought behind the design.\n\n## Subsystems\n\nExternal users interact with services, made available via a GRPC API.\n\n- __*Distribution*__: The distribution service supports pulling images.\n- __*Bundle*__: The bundle service allows the user to extract and pack bundles\n  from disk images.\n- __*Runtime*__: The runtime service supports the execution of _bundles_,\n  including the creation of runtime containers.\n\nTypically, each subsystem will have one or more related _controller_ components\nthat implement the behavior of the _subsystem_. The behavior of the _subsystem_\nmay be exported for access via corresponding _services_.\n\n## Modules\n\nIn addition to the subsystems have, we have several components that may cross\nsubsystem boundaries, referenced to as components. We have the following\ncomponents:\n\n- __*Executor*__: The executor implements the actual container runtime.\n- __*Supervisor*__: The supervisor monitors and reports container state.\n- __*Metadata*__: Stores metadata in a graph database. Use to store any\n  persistent references to images and bundles. Data entered into the\n  database will have schemas coordinated between components to provide access\n  to arbitrary data. Other functionality includes hooks for garbage collection\n  of on-disk resources.\n- __*Content*__: Provides access to content addressable storage. All immutable\n  content will be stored here, keyed by content hash.\n- __*Snapshot*__: Manages filesystem snapshots for container images. This is\n  analogous to the graphdriver in Docker today. Layers are unpacked into\n  snapshots.\n- __*Events*__: Supports the collection and consumption of events for providing\n  consistent, event driven behavior and auditing. Events may be replayed to\n  various _modules_\n- __*Metrics*__: Each components will export several metrics, accessible via\n  the metrics API. (We may want to promote this to a subsystem.\n\n## Data Flow\n\nAs discussed above, the concept of a _bundle_ is central to containerd. Below\nis a diagram illustrating the data flow for bundle creation.\n\n![data-flow](data-flow.png)\n\nLet's take pulling an image as a demonstrated example:\n\n1. Instruct the Distribution layer to pull a particular image. The distribution\n   layer places the image content into the _content store_. The image name and\n   root manifest pointers are registered with the metadata store.\n2. Once the image is pulled, the user can instruct the bundle controller to\n   unpack the image into a bundle. Consuming from the content store, _layers_\n   from the image are unpacked into the _snapshot_ component.\n3. When the snapshot for the rootfs of a container is ready, the _bundle\n   controller_ can use the image manifest and config to prepare the execution\n   configuration. Part of this is entering mounts into the execution config\n   from the _snapshot_ module.\n4. The prepared bundle is then passed off to the _runtime_ subsystem for\n   execution. It reads the bundle configuration to create a running container.\n\n","vendor/github.com/matttproud/golang_protobuf_extensions/README.md":"# Overview\nThis repository provides various Protocol Buffer extensions for the Go\nlanguage (golang), namely support for record length-delimited message\nstreaming.\n\n| Java                           | Go                    |\n| ------------------------------ | --------------------- |\n| MessageLite#parseDelimitedFrom | pbutil.ReadDelimited  |\n| MessageLite#writeDelimitedTo   | pbutil.WriteDelimited |\n\nBecause [Code Review 9102043](https://codereview.appspot.com/9102043/) is\ndestined to never be merged into mainline (i.e., never be promoted to formal\n[goprotobuf features](https://github.com/golang/protobuf)), this repository\nwill live here in the wild.\n\n# Documentation\nWe have [generated Go Doc documentation](http://godoc.org/github.com/matttproud/golang_protobuf_extensions/pbutil) here.\n\n# Testing\n[![Build Status](https://travis-ci.org/matttproud/golang_protobuf_extensions.png?branch=master)](https://travis-ci.org/matttproud/golang_protobuf_extensions)\n"},"items":[{"name":"architecture.md","path":"design/architecture.md","rawUrl":"https://raw.githubusercontent.com/docker/containerd/HEAD/design/architecture.md","title":"design - System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# Architecture\n\nTo ensure clean separation of concerns, we have organized the units of\ncontainerd's behavior into _components_. _Components_ are roughly organized\ninto _subsystems_. _Components_ that bridge subsystems may be referred to as\n_modules_. _Modules_ typically provide cross-cutting functionality, such as\npersistent storage or event distribution. Understanding these _components_ and\ntheir relationships is key to modifying and extending the system.\n\nThis document will cover very high-level interaction. For details on each\nmodule, please see the relevant design document.\n\nThe main goal of this architecture is to coordinate the creation and execution\nof _bundles_.  _Bundles_ contain configuration, metadata and root filesystem\ndata and are consumed by the _runtime_. A _bundle_ is the on-disk\nrepresentation of a runtime container. _Bundles_ are mutable and can be passed\nto other systems for modification or packed up and distributed. In practice, it\nis simply a directory on the filesystem. \n\n![Architecture](architecture.png)\n\nNote that while these architectural ideas are important to understanding the\nsystem, code layout may not reflect the exact architecture. These ideas should\nbe used as a guide for placing functionality and behavior and understanding the\nthought behind the design.\n\n## Subsystems\n\nExternal users interact with services, made available via a GRPC API.\n\n- __*Distribution*__: The distribution service supports pulling images.\n- __*Bundle*__: The bundle service allows the user to extract and pack bundles\n  from disk images.\n- __*Runtime*__: The runtime service supports the execution of _bundles_,\n  including the creation of runtime containers.\n\nTypically, each subsystem will have one or more related _controller_ components\nthat implement the behavior of the _subsystem_. The behavior of the _subsystem_\nmay be exported for access via corresponding _services_.\n\n## Modules\n\nIn addition to the subsystems have, we have several components that may cross\nsubsystem boundaries, referenced to as components. We have the following\ncomponents:\n\n- __*Executor*__: The executor implements the actual container runtime.\n- __*Supervisor*__: The supervisor monitors and reports container state.\n- __*Metadata*__: Stores metadata in a graph database. Use to store any\n  persistent references to images and bundles. Data entered into the\n  database will have schemas coordinated between components to provide access\n  to arbitrary data. Other functionality includes hooks for garbage collection\n  of on-disk resources.\n- __*Content*__: Provides access to content addressable storage. All immutable\n  content will be stored here, keyed by content hash.\n- __*Snapshot*__: Manages filesystem snapshots for container images. This is\n  analogous to the graphdriver in Docker today. Layers are unpacked into\n  snapshots.\n- __*Events*__: Supports the collection and consumption of events for providing\n  consistent, event driven behavior and auditing. Events may be replayed to\n  various _modules_\n- __*Metrics*__: Each components will export several metrics, accessible via\n  the metrics API. (We may want to promote this to a subsystem.\n\n## Data Flow\n\nAs discussed above, the concept of a _bundle_ is central to containerd. Below\nis a diagram illustrating the data flow for bundle creation.\n\n![data-flow](data-flow.png)\n\nLet's take pulling an image as a demonstrated example:\n\n1. Instruct the Distribution layer to pull a particular image. The distribution\n   layer places the image content into the _content store_. The image name and\n   root manifest pointers are registered with the metadata store.\n2. Once the image is pulled, the user can instruct the bundle controller to\n   unpack the image into a bundle. Consuming from the content store, _layers_\n   from the image are unpacked into the _snapshot_ component.\n3. When the snapshot for the rootfs of a container is ready, the _bundle\n   controller_ can use the image manifest and config to prepare the execution\n   configuration. Part of this is entering mounts into the execution config\n   from the _snapshot_ module.\n4. The prepared bundle is then passed off to the _runtime_ subsystem for\n   execution. It reads the bundle configuration to create a running container.\n\n","isInternal":false,"tokens":873,"sizeBytes":4255},{"name":"README.md","path":"vendor/github.com/matttproud/golang_protobuf_extensions/README.md","rawUrl":"https://raw.githubusercontent.com/docker/containerd/HEAD/vendor/github.com/matttproud/golang_protobuf_extensions/README.md","title":"golang_protobuf_extensions Documentation","category":"plugin-manifest","format":"markdown","content":"# Overview\nThis repository provides various Protocol Buffer extensions for the Go\nlanguage (golang), namely support for record length-delimited message\nstreaming.\n\n| Java                           | Go                    |\n| ------------------------------ | --------------------- |\n| MessageLite#parseDelimitedFrom | pbutil.ReadDelimited  |\n| MessageLite#writeDelimitedTo   | pbutil.WriteDelimited |\n\nBecause [Code Review 9102043](https://codereview.appspot.com/9102043/) is\ndestined to never be merged into mainline (i.e., never be promoted to formal\n[goprotobuf features](https://github.com/golang/protobuf)), this repository\nwill live here in the wild.\n\n# Documentation\nWe have [generated Go Doc documentation](http://godoc.org/github.com/matttproud/golang_protobuf_extensions/pbutil) here.\n\n# Testing\n[![Build Status](https://travis-ci.org/matttproud/golang_protobuf_extensions.png?branch=master)](https://travis-ci.org/matttproud/golang_protobuf_extensions)\n","isInternal":false,"tokens":220,"sizeBytes":963}],"systemPromptSnippet":"<yakaai_skills repo=\"docker/containerd\">\n<!-- File: design/architecture.md (Tokens: ~873 | Category: project-spec) -->\n# Architecture\n\nTo ensure clean separation of concerns, we have organized the units of\ncontainerd's behavior into _components_. _Components_ are roughly organized\ninto _subsystems_. _Components_ that bridge subsystems may be referred to as\n_modules_. _Modules_ typically provide cross-cutting functionality, such as\npersistent storage or event distribution. Understanding these _components_ and\ntheir relationships is key to modifying and extending the system.\n\nThis document will cover very high-level interaction. For details on each\nmodule, please see the relevant design document.\n\nThe main goal of this architecture is to coordinate the creation and execution\nof _bundles_.  _Bundles_ contain configuration, metadata and root filesystem\ndata and are consumed by the _runtime_. A _bundle_ is the on-disk\nrepresentation of a runtime container. _Bundles_ are mutable and can be passed\nto other systems for modification or packed up and distributed. In practice, it\nis simply a directory on the filesystem. \n\n![Architecture](architecture.png)\n\nNote that while these architectural ideas are important to understanding the\nsystem, code layout may not reflect the exact architecture. These ideas should\nbe used as a guide for placing functionality and behavior and understanding the\nthought behind the design.\n\n## Subsystems\n\nExternal users interact with services, made available via a GRPC API.\n\n- __*Distribution*__: The distribution service supports pulling images.\n- __*Bundle*__: The bundle service allows the user to extract and pack bundles\n  from disk images.\n- __*Runtime*__: The runtime service supports the execution of _bundles_,\n  including the creation of runtime containers.\n\nTypically, each subsystem will have one or more related _controller_ components\nthat implement the behavior of the _subsystem_. The behavior of the _subsystem_\nmay be exported for access via corresponding _services_.\n\n## Modules\n\nIn addition to the subsystems have, we have several components that may cross\nsubsystem boundaries, referenced to as components. We have the following\ncomponents:\n\n- __*Executor*__: The executor implements the actual container runtime.\n- __*Supervisor*__: The supervisor monitors and reports container state.\n- __*Metadata*__: Stores metadata in a graph database. Use to store any\n  persistent references to images and bundles. Data entered into the\n  database will have schemas coordinated between components to provide access\n  to arbitrary data. Other functionality includes hooks for garbage collection\n  of on-disk resources.\n- __*Content*__: Provides access to content addressable storage. All immutable\n  content will be stored here, keyed by content hash.\n- __*Snapshot*__: Manages filesystem snapshots for container images. This is\n  analogous to the graphdriver in Docker today. Layers are unpacked into\n  snapshots.\n- __*Events*__: Supports the collection and consumption of events for providing\n  consistent, event driven behavior and auditing. Events may be replayed to\n  various _modules_\n- __*Metrics*__: Each components will export several metrics, accessible via\n  the metrics API. (We may want to promote this to a subsystem.\n\n## Data Flow\n\nAs discussed above, the concept of a _bundle_ is central to containerd. Below\nis a diagram illustrating the data flow for bundle creation.\n\n![data-flow](data-flow.png)\n\nLet's take pulling an image as a demonstrated example:\n\n1. Instruct the Distribution layer to pull a particular image. The distribution\n   layer places the image content into the _content store_. The image name and\n   root manifest pointers are registered with the metadata store.\n2. Once the image is pulled, the user can instruct the bundle controller to\n   unpack the image into a bundle. Consuming from the content store, _layers_\n   from the image are unpacked into the _snapshot_ component.\n3. When the snapshot for the rootfs of a container is ready, the _bundle\n   controller_ can use the image manifest and config to prepare the execution\n   configuration. Part of this is entering mounts into the execution config\n   from the _snapshot_ module.\n4. The prepared bundle is then passed off to the _runtime_ subsystem for\n   execution. It reads the bundle configuration to create a running container.\n\n<!-- File: vendor/github.com/matttproud/golang_protobuf_extensions/README.md (Tokens: ~220 | Category: plugin-manifest) -->\n# Overview\nThis repository provides various Protocol Buffer extensions for the Go\nlanguage (golang), namely support for record length-delimited message\nstreaming.\n\n| Java                           | Go                    |\n| ------------------------------ | --------------------- |\n| MessageLite#parseDelimitedFrom | pbutil.ReadDelimited  |\n| MessageLite#writeDelimitedTo   | pbutil.WriteDelimited |\n\nBecause [Code Review 9102043](https://codereview.appspot.com/9102043/) is\ndestined to never be merged into mainline (i.e., never be promoted to formal\n[goprotobuf features](https://github.com/golang/protobuf)), this repository\nwill live here in the wild.\n\n# Documentation\nWe have [generated Go Doc documentation](http://godoc.org/github.com/matttproud/golang_protobuf_extensions/pbutil) here.\n\n# Testing\n[![Build Status](https://travis-ci.org/matttproud/golang_protobuf_extensions.png?branch=master)](https://travis-ci.org/matttproud/golang_protobuf_extensions)\n</yakaai_skills>"}