github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/book/02-concepts/01-packages.md (about) 1 A kpt package is a bundle of configuration _data_. It is represented as a 2 directory tree containing KRM resources using YAML as the file format. 3 4 A package is explicitly declared using a file named `Kptfile` containing a KRM 5 resource of kind `Kptfile`. The Kptfile contains metadata about the package and 6 is just a regular resource in the YAML format. 7 8 Just as directories can be nested, a package can contain another package, called 9 a _subpackage_. 10 11 Let's take a look at the wordpress package as an example: 12 13 ```shell 14 $ kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9 15 ``` 16 17 View the package hierarchy using the `tree` command: 18 19 ```shell 20 $ kpt pkg tree wordpress/ 21 Package "wordpress" 22 ├── [Kptfile] Kptfile wordpress 23 ├── [service.yaml] Service wordpress 24 ├── deployment 25 │ ├── [deployment.yaml] Deployment wordpress 26 │ └── [volume.yaml] PersistentVolumeClaim wp-pv-claim 27 └── Package "mysql" 28 ├── [Kptfile] Kptfile mysql 29 ├── [deployment.yaml] PersistentVolumeClaim mysql-pv-claim 30 ├── [deployment.yaml] Deployment wordpress-mysql 31 └── [deployment.yaml] Service wordpress-mysql 32 ``` 33 34 This _package hierarchy_ contains two packages: 35 36 1. `wordpress` is the top-level package in the hierarchy declared using 37 `wordpress/Kptfile`. This package contains 2 subdirectories. 38 `wordpress/deployment` is a regular directory used for organizing resources 39 that belong to the `wordpress` package itself. The `wordpress` package 40 contains 3 direct resources in 3 files: `service.yaml`, 41 `deployment/deployment.yaml`, and `deployment/volume.yaml`. 42 2. `wordpress/mysql` is a subpackage of `wordpress` package since it contains a 43 `Kptfile`. This package contains 3 resources in 44 `wordpress/mysql/deployment.yaml` file. 45 46 kpt uses Git as the underlying version control system. A typical workflow starts 47 by fetching an _upstream_ package from a Git repository to the local filesystem 48 using `kpt pkg` commands. All other functionality (i.e. `kpt fn` and `kpt live`) 49 use the package from the local filesystem, not the remote Git repository. You 50 may think of this as the _vendoring_ used by tooling for some programming 51 languages. The main difference is that kpt is designed to enable you to modify 52 the vendored package on the local filesystem and then later update the package 53 by merging the local and upstream changes. 54 55 There is one scenario where a Kptfile is implicit: You can use kpt to fetch any 56 Git directory containing KRM resources, even if it does not contain a `Kptfile`. 57 Effectively, you are telling kpt to treat that Git directory as a package. kpt 58 automatically creates the `Kptfile` on the local filesystem to keep track of the 59 upstream repo. This means that kpt is compatible with large corpus of existing 60 Kubernetes configuration stored on Git today! 61 62 For example, `cockroachdb` is just a vanilla directory of KRM: 63 64 ```shell 65 $ kpt pkg get https://github.com/kubernetes/examples/staging/cockroachdb 66 ``` 67 68 We will go into details of how to work with packages in [Chapter 3]. 69 70 [chapter 3]: /book/03-packages/