From ece71412c0294a4436935935346f7ea495adce01 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Tue, 7 Jan 2020 09:39:44 +0100 Subject: [PATCH] vendor: bump buildkit 4f4e03067523b2fc5ca2f17514a5e75ad63e02fb full diff: https://github.com/moby/buildkit/compare/f7042823e340d38d1746aa675b83d1aca431cee3...4f4e03067523b2fc5ca2f17514a5e75ad63e02fb no changes to vendored files Signed-off-by: Sebastiaan van Stijn --- vendor.conf | 2 +- vendor/github.com/moby/buildkit/README.md | 360 ++++++++++++++-------- vendor/github.com/moby/buildkit/go.mod | 2 +- 3 files changed, 228 insertions(+), 136 deletions(-) diff --git a/vendor.conf b/vendor.conf index 30d9b14ff2..bb533f3925 100755 --- a/vendor.conf +++ b/vendor.conf @@ -45,7 +45,7 @@ github.com/Microsoft/go-winio 6c72808b55902eae4c5943626030 github.com/Microsoft/hcsshim b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2 github.com/miekg/pkcs11 cb39313ec884f2cd77f4762875fe96aecf68f8e3 # v1.0.2 github.com/mitchellh/mapstructure f15292f7a699fcc1a38a80977f80a046874ba8ac -github.com/moby/buildkit f7042823e340d38d1746aa675b83d1aca431cee3 # v0.6.1-71-gf7042823 +github.com/moby/buildkit 4f4e03067523b2fc5ca2f17514a5e75ad63e02fb github.com/modern-go/concurrent bacd9c7ef1dd9b15be4a9909b8ac7a4e313eec94 # 1.0.3 github.com/modern-go/reflect2 4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd # 1.0.1 github.com/morikuni/aec 39771216ff4c63d11f5e604076f9c45e8be1067b diff --git a/vendor/github.com/moby/buildkit/README.md b/vendor/github.com/moby/buildkit/README.md index b75d4c7f80..d2b0a6c7b5 100644 --- a/vendor/github.com/moby/buildkit/README.md +++ b/vendor/github.com/moby/buildkit/README.md @@ -1,6 +1,6 @@ [![asciicinema example](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU.png)](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU) -## BuildKit +# BuildKit [![GoDoc](https://godoc.org/github.com/moby/buildkit?status.svg)](https://godoc.org/github.com/moby/buildkit/client/llb) [![Build Status](https://travis-ci.org/moby/buildkit.svg?branch=master)](https://travis-ci.org/moby/buildkit) @@ -25,49 +25,107 @@ Read the proposal from https://github.com/moby/moby/issues/32925 Introductory blog post https://blog.mobyproject.org/introducing-buildkit-17e056cc5317 +Join `#buildkit` channel on [Docker Community Slack](http://dockr.ly/slack) + :information_source: If you are visiting this repo for the usage of experimental Dockerfile features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`, please refer to [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md). -### Used by +:information_source: [BuildKit has been integrated to `docker build` since Docker 18.06 .](https://docs.docker.com/develop/develop-images/build_enhancements/) +You don't need to read this document unless you want to use the full-featured standalone version of BuildKit. + + + + + +- [Used by](#used-by) +- [Quick start](#quick-start) + - [Starting the `buildkitd` daemon:](#starting-the-buildkitd-daemon) + - [Exploring LLB](#exploring-llb) + - [Exploring Dockerfiles](#exploring-dockerfiles) + - [Building a Dockerfile with `buildctl`](#building-a-dockerfile-with-buildctl) + - [Building a Dockerfile using external frontend:](#building-a-dockerfile-using-external-frontend) + - [Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`](#building-a-dockerfile-with-experimental-features-like-run---mounttypebindcachetmpfssecretssh) + - [Output](#output) + - [Registry](#registry) + - [Local directory](#local-directory) + - [Docker tarball](#docker-tarball) + - [OCI tarball](#oci-tarball) + - [containerd image store](#containerd-image-store) +- [Cache](#cache) + - [Garbage collection](#garbage-collection) + - [Export cache](#export-cache) + - [Inline (push image and cache together)](#inline-push-image-and-cache-together) + - [Registry (push image and cache separately)](#registry-push-image-and-cache-separately) + - [Local directory](#local-directory-1) + - [`--export-cache` options](#--export-cache-options) + - [`--import-cache` options](#--import-cache-options) + - [Consistent hashing](#consistent-hashing) +- [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service) + - [Load balancing](#load-balancing) +- [Containerizing BuildKit](#containerizing-buildkit) + - [Kubernetes](#kubernetes) + - [Daemonless](#daemonless) +- [Opentracing support](#opentracing-support) +- [Running BuildKit without root privileges](#running-buildkit-without-root-privileges) +- [Building multi-platform images](#building-multi-platform-images) +- [Contributing](#contributing) + + + +## Used by BuildKit is used by the following projects: -- [Moby & Docker](https://github.com/moby/moby/pull/37151) +- [Moby & Docker](https://github.com/moby/moby/pull/37151) (`DOCKER_BUILDKIT=1 docker build`) - [img](https://github.com/genuinetools/img) - [OpenFaaS Cloud](https://github.com/openfaas/openfaas-cloud) - [container build interface](https://github.com/containerbuilding/cbi) -- [Knative Build Templates](https://github.com/knative/build-templates) +- [Tekton Pipelines](https://github.com/tektoncd/catalog) (formerly [Knative Build Templates](https://github.com/knative/build-templates)) - [the Sanic build tool](https://github.com/distributed-containers-inc/sanic) - [vab](https://github.com/stellarproject/vab) - [Rio](https://github.com/rancher/rio) +- [PouchContainer](https://github.com/alibaba/pouch) +- [Docker buildx](https://github.com/docker/buildx) -### Quick start +## Quick start -Dependencies: +:information_source: For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes). +BuildKit is composed of the `buildkitd` daemon and the `buildctl` client. +While the `buildctl` client is available for Linux, macOS, and Windows, the `buildkitd` daemon is only available for Linux currently. + +The `buildkitd` daemon requires the following components to be installed: - [runc](https://github.com/opencontainers/runc) - [containerd](https://github.com/containerd/containerd) (if you want to use containerd worker) -The following command installs `buildkitd` and `buildctl` to `/usr/local/bin`: +The latest binaries of BuildKit are available [here](https://github.com/moby/buildkit/releases) for Linux, macOS, and Windows. -```bash -$ make && sudo make install +[Homebrew package](https://formulae.brew.sh/formula/buildkit) (unofficial) is available for macOS. +```console +$ brew install buildkit ``` -You can also use `make binaries-all` to prepare `buildkitd.containerd_only` and `buildkitd.oci_only`. +To build BuildKit from source, see [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md). -#### Starting the buildkitd daemon: +### Starting the `buildkitd` daemon: + +You need to run `buildkitd` as the root user on the host. ```bash -buildkitd --debug --root /var/lib/buildkit +$ sudo buildkitd ``` +To run `buildkitd` as a non-root user, see [`docs/rootless.md`](docs/rootless.md). + The buildkitd daemon supports two worker backends: OCI (runc) and containerd. By default, the OCI (runc) worker is used. You can set `--oci-worker=false --containerd-worker=true` to use the containerd worker. We are open to adding more backends. -#### Exploring LLB +The buildkitd daemon listens gRPC API on `/run/buildkit/buildkitd.sock` by default, but you can also use TCP sockets. +See [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service). + +### Exploring LLB BuildKit builds are based on a binary intermediate format called LLB that is used for defining the dependency graph for processes running part of your build. tl;dr: LLB is to Dockerfile what LLVM IR is to C. @@ -76,49 +134,23 @@ BuildKit builds are based on a binary intermediate format called LLB that is use - Efficiently cacheable - Vendor-neutral (i.e. non-Dockerfile languages can be easily implemented) -See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition. +See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition, and see [`./examples/README.md`](./examples/README.md) for example LLB applications. -Currently, following high-level languages has been implemented for LLB: +Currently, the following high-level languages has been implemented for LLB: - Dockerfile (See [Exploring Dockerfiles](#exploring-dockerfiles)) - [Buildpacks](https://github.com/tonistiigi/buildkit-pack) +- [Mockerfile](https://matt-rickard.com/building-a-new-dockerfile-frontend/) +- [Gockerfile](https://github.com/po3rin/gockerfile) - (open a PR to add your own language) -For understanding the basics of LLB, `examples/buildkit*` directory contains scripts that define how to build different configurations of BuildKit itself and its dependencies using the `client` package. Running one of these scripts generates a protobuf definition of a build graph. Note that the script itself does not execute any steps of the build. +### Exploring Dockerfiles -You can use `buildctl debug dump-llb` to see what data is in this definition. Add `--dot` to generate dot layout. +Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (`gateway.v0`) that allows using any image as a frontend. -```bash -go run examples/buildkit0/buildkit.go \ - | buildctl debug dump-llb \ - | jq . -``` +During development, Dockerfile frontend (`dockerfile.v0`) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image. -To start building use `buildctl build` command. The example script accepts `--with-containerd` flag to choose if containerd binaries and support should be included in the end result as well. - -```bash -go run examples/buildkit0/buildkit.go \ - | buildctl build -``` - -`buildctl build` will show interactive progress bar by default while the build job is running. If the path to the trace file is specified, the trace file generated will contain all information about the timing of the individual steps and logs. - -Different versions of the example scripts show different ways of describing the build definition for this project to show the capabilities of the library. New versions have been added when new features have become available. - -- `./examples/buildkit0` - uses only exec operations, defines a full stage per component. -- `./examples/buildkit1` - cloning git repositories has been separated for extra concurrency. -- `./examples/buildkit2` - uses git sources directly instead of running `git clone`, allowing better performance and much safer caching. -- `./examples/buildkit3` - allows using local source files for separate components eg. `./buildkit3 --runc=local | buildctl build --local runc-src=some/local/path` -- `./examples/dockerfile2llb` - can be used to convert a Dockerfile to LLB for debugging purposes -- `./examples/gobuild` - shows how to use nested invocation to generate LLB for Go package internal dependencies - -#### Exploring Dockerfiles - -Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (gateway.v0) that allows using any image as a frontend. - -During development, Dockerfile frontend (dockerfile.v0) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image. - -##### Building a Dockerfile with `buildctl` +#### Building a Dockerfile with `buildctl` ```bash buildctl build \ @@ -136,22 +168,7 @@ buildctl build \ `--local` exposes local source files from client to the builder. `context` and `dockerfile` are the names Dockerfile frontend looks for build context and Dockerfile location. -##### build-using-dockerfile utility - -For people familiar with `docker build` command, there is an example wrapper utility in `./examples/build-using-dockerfile` that allows building Dockerfiles with BuildKit using a syntax similar to `docker build`. - -```bash -go build ./examples/build-using-dockerfile \ - && sudo install build-using-dockerfile /usr/local/bin - -build-using-dockerfile -t myimage . -build-using-dockerfile -t mybuildkit -f ./hack/dockerfiles/test.Dockerfile . - -# build-using-dockerfile will automatically load the resulting image to Docker -docker inspect myimage -``` - -##### Building a Dockerfile using [external frontend](https://hub.docker.com/r/docker/dockerfile/tags/): +#### Building a Dockerfile using external frontend: External versions of the Dockerfile frontend are pushed to https://hub.docker.com/r/docker/dockerfile-upstream and https://hub.docker.com/r/docker/dockerfile and can be used with the gateway frontend. The source for the external frontend is currently located in `./frontend/dockerfile/cmd/dockerfile-frontend` but will move out of this repository in the future ([#163](https://github.com/moby/buildkit/issues/163)). For automatic build from master branch of this repository `docker/dockerfile-upsteam:master` or `docker/dockerfile-upstream:master-experimental` image can be used. @@ -168,7 +185,7 @@ buildctl build \ --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org ``` -##### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)` +#### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)` See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md). @@ -176,24 +193,26 @@ See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experi By default, the build result and intermediate cache will only remain internally in BuildKit. An output needs to be specified to retrieve the result. -##### Exporting resulting image to containerd - -The containerd worker needs to be used - -```bash -buildctl build ... --output type=image,name=docker.io/username/image -ctr --namespace=buildkit images ls -``` - -##### Push resulting image to registry +#### Registry ```bash buildctl build ... --output type=image,name=docker.io/username/image,push=true ``` -If credentials are required, `buildctl` will attempt to read Docker configuration file. +To export and import the cache along with the image, you need to specify `--export-cache type=inline` and `--import-cache type=registry,ref=...`. +See [Export cache](#export-cache). -##### Exporting build result back to client +```bash +buildctl build ...\ + --output type=image,name=docker.io/username/image,push=true \ + --export-cache type=inline \ + --import-cache type=registry,ref=docker.io/username/image +``` + +If credentials are required, `buildctl` will attempt to read Docker configuration file `$DOCKER_CONFIG/config.json`. +`$DOCKER_CONFIG` defaults to `~/.docker`. + +#### Local directory The local client will copy the files directly to the client. This is useful if BuildKit is being used for building something else than container images. @@ -222,70 +241,150 @@ buildctl build ... --output type=tar,dest=out.tar buildctl build ... --output type=tar > out.tar ``` -##### Exporting built image to Docker +#### Docker tarball ```bash # exported tarball is also compatible with OCI spec buildctl build ... --output type=docker,name=myimage | docker load ``` -##### Exporting [OCI Image Format](https://github.com/opencontainers/image-spec) tarball to client +#### OCI tarball ```bash buildctl build ... --output type=oci,dest=path/to/output.tar buildctl build ... --output type=oci > output.tar ``` +#### containerd image store -### Exporting/Importing build cache (not image itself) - -#### To/From registry +The containerd worker needs to be used ```bash -buildctl build ... --export-cache type=registry,ref=localhost:5000/myrepo:buildcache -buildctl build ... --import-cache type=registry,ref=localhost:5000/myrepo:buildcache +buildctl build ... --output type=image,name=docker.io/username/image +ctr --namespace=buildkit images ls ``` -#### To/From local filesystem +To change the containerd namespace, you need to change `worker.containerd.namespace` in [`/etc/buildkit/buildkitd.toml`](./docs/buildkitd.toml.md). -```bash -buildctl build ... --export-cache type=local,dest=path/to/output-dir -buildctl build ... --import-cache type=local,src=path/to/input-dir -``` -The directory layout conforms to OCI Image Spec v1.0. +## Cache -#### `--export-cache` options - -- `mode=min` (default): only export layers for the resulting image -- `mode=max`: export all the layers of all intermediate steps -- `ref=docker.io/user/image:tag`: reference for `registry` cache exporter -- `dest=path/to/output-dir`: directory for `local` cache exporter - -#### `--import-cache` options - -- `ref=docker.io/user/image:tag`: reference for `registry` cache importer -- `src=path/to/input-dir`: directory for `local` cache importer -- `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer. Defaults to the digest of "latest" tag in `index.json` - -### Other - -#### View build cache +To show local build cache (`/var/lib/buildkit`): ```bash buildctl du -v ``` -#### Show enabled workers - +To prune local build cache: ```bash -buildctl debug workers -v +buildctl prune ``` -### Running containerized buildkit +### Garbage collection -BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely. The client tool `buildctl` is also available for Mac and Windows. +See [`./docs/buildkitd.toml.md`](./docs/buildkitd.toml.md). -We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/): +### Export cache + +BuildKit supports the following cache exporters: +* `inline`: embed the cache into the image, and push them to the registry together +* `registry`: push the image and the cache separately +* `local`: export to a local directory + +In most case you want to use the `inline` cache exporter. +However, note that the `inline` cache exporter only supports `min` cache mode. +To enable `max` cache mode, push the image and the cache separately by using `registry` cache exporter. + +#### Inline (push image and cache together) + +```bash +buildctl build ... \ + --output type=image,name=docker.io/username/image,push=true \ + --export-cache type=inline \ + --import-cache type=registry,ref=docker.io/username/image +``` + +Note that the inline cache is not imported unless `--import-cache type=registry,ref=...` is provided. + +:information_source: Docker-integrated BuildKit (`DOCKER_BUILDKIT=1 docker build`) and `docker buildx`requires +`--build-arg BUILDKIT_INLINE_CACHE=1` to be specified to enable the `inline` cache exporter. +However, the standalone `buildctl` does NOT require `--opt build-arg:BUILDKIT_INLINE_CACHE=1` and the build-arg is simply ignored. + +#### Registry (push image and cache separately) + +```bash +buildctl build ... \ + --output type=image,name=localhost:5000/myrepo:image,push=true \ + --export-cache type=registry,ref=localhost:5000/myrepo:buildcache \ + --import-cache type=registry,ref=localhost:5000/myrepo:buildcache \ +``` + +#### Local directory + +```bash +buildctl build ... --export-cache type=local,dest=path/to/output-dir +buildctl build ... --import-cache type=local,src=path/to/input-dir,digest=sha256:deadbeef +``` + +The directory layout conforms to OCI Image Spec v1.0. + +Currently, you need to specify the `digest` of the manifest list to import for `local` cache importer. +This is planned to default to the digest of "latest" tag in `index.json` in future. + +#### `--export-cache` options +- `type`: `inline`, `registry`, or `local` +- `mode=min` (default): only export layers for the resulting image +- `mode=max`: export all the layers of all intermediate steps. Not supported for `inline` cache exporter. +- `ref=docker.io/user/image:tag`: reference for `registry` cache exporter +- `dest=path/to/output-dir`: directory for `local` cache exporter + +#### `--import-cache` options +- `type`: `registry` or `local`. Use `registry` to import `inline` cache. +- `ref=docker.io/user/image:tag`: reference for `registry` cache importer +- `src=path/to/input-dir`: directory for `local` cache importer +- `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer. + +### Consistent hashing + +If you have multiple BuildKit daemon instances but you don't want to use registry for sharing cache across the cluster, +consider client-side load balancing using consistent hashing. + +See [`./examples/kubernetes/consistenthash`](./examples/kubernetes/consistenthash). + +## Expose BuildKit as a TCP service + +The `buildkitd` daemon can listen the gRPC API on a TCP socket. + +It is highly recommended to create TLS certificates for both the daemon and the client (mTLS). +Enabling TCP without mTLS is dangerous because the executor containers (aka Dockerfile `RUN` containers) can call BuildKit API as well. + +```bash +buildkitd \ + --addr tcp://0.0.0.0:1234 \ + --tlscacert /path/to/ca.pem \ + --tlscert /path/to/cert.pem \ + --tlskey /path/to/key.pem +``` + +```bash +buildctl \ + --addr tcp://example.com:1234 \ + --tlscacert /path/to/ca.pem \ + --tlscert /path/to/clientcert.pem \ + --tlskey /path/to/clientkey.pem \ + build ... +``` + +### Load balancing + +`buildctl build` can be called against randomly load balanced the `buildkitd` daemon. + +See also [Consistent hashing](#consistenthashing) for client-side load balancing. + +## Containerizing BuildKit + +BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely. + +We provide the container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/): - `moby/buildkit:latest`: built from the latest regular [release](https://github.com/moby/buildkit/releases) - `moby/buildkit:rootless`: same as `latest` but runs as an unprivileged user, see [`docs/rootless.md`](docs/rootless.md) @@ -295,11 +394,17 @@ We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker. To run daemon in a container: ```bash -docker run -d --privileged -p 1234:1234 moby/buildkit:latest --addr tcp://0.0.0.0:1234 -export BUILDKIT_HOST=tcp://0.0.0.0:1234 +docker run -d --name buildkitd --privileged moby/buildkit:latest +export BUILDKIT_HOST=docker-container://buildkitd buildctl build --help ``` +### Kubernetes + +For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes). + +### Daemonless + To run client and an ephemeral daemon in a single container ("daemonless mode"): ```bash @@ -335,21 +440,7 @@ docker run \ --local dockerfile=/tmp/work ``` -The images can be also built locally using `./hack/dockerfiles/test.Dockerfile` (or `./hack/dockerfiles/test.buildkit.Dockerfile` if you already have BuildKit). Run `make images` to build the images as `moby/buildkit:local` and `moby/buildkit:local-rootless`. - -#### Connection helpers - -If you are running `moby/buildkit:master` or `moby/buildkit:master-rootless` as a Docker/Kubernetes container, you can use special `BUILDKIT_HOST` URL for connecting to the BuildKit daemon in the container: - -```bash -export BUILDKIT_HOST=docker-container:// -``` - -```bash -export BUILDKIT_HOST=kube-pod:// -``` - -### Opentracing support +## Opentracing support BuildKit supports opentracing for buildkitd gRPC API and buildctl commands. To capture the trace to [Jaeger](https://github.com/jaegertracing/jaeger), set `JAEGER_TRACE` environment variable to the collection address. @@ -360,14 +451,15 @@ export JAEGER_TRACE=0.0.0.0:6831 # any buildctl command should be traced to http://127.0.0.1:16686/ ``` -### Supported runc version - -During development, BuildKit is tested with the version of runc that is being used by the containerd repository. Please refer to [runc.md](https://github.com/containerd/containerd/blob/v1.2.1/RUNC.md) for more information. - -### Running BuildKit without root privileges +## Running BuildKit without root privileges Please refer to [`docs/rootless.md`](docs/rootless.md). -### Contributing +## Building multi-platform images + +See [`docker buildx` documentation](https://github.com/docker/buildx#building-multi-platform-images) + +## Contributing Want to contribute to BuildKit? Awesome! You can find information about contributing to this project in the [CONTRIBUTING.md](/.github/CONTRIBUTING.md) + diff --git a/vendor/github.com/moby/buildkit/go.mod b/vendor/github.com/moby/buildkit/go.mod index c2b385b359..637b15b902 100644 --- a/vendor/github.com/moby/buildkit/go.mod +++ b/vendor/github.com/moby/buildkit/go.mod @@ -9,7 +9,7 @@ require ( github.com/codahale/hdrhistogram v0.0.0-20160425231609-f8ad88b59a58 // indirect github.com/containerd/cgroups v0.0.0-20190717030353-c4b9ac5c7601 // indirect github.com/containerd/console v0.0.0-20181022165439-0650fd9eeb50 - github.com/containerd/containerd v1.3.0 + github.com/containerd/containerd v1.4.0-0.20191014053712-acdcf13d5eaf github.com/containerd/continuity v0.0.0-20190827140505-75bee3e2ccb6 github.com/containerd/fifo v0.0.0-20190816180239-bda0ff6ed73c // indirect github.com/containerd/go-cni v0.0.0-20190813230227-49fbd9b210f3