github.com/lalkh/containerd@v1.4.3/reports/2017-05-26.md (about)

     1  # Development Report for May 26, 2017
     2  
     3  ## Project Status
     4  
     5  Overall, containerd is very close to being feature complete.  The final features like namespace support are being worked on.  We have a couple consumers that are working on containerd implementations such as a CRI for kube, Docker execution, Swarmkit, and Linuxkit consuming containerd.
     6  
     7  We hope to be feature complete by the end of this month.  That will leave the month of June to focus on quality of the API and making sure that client needs are met.  We have some work on error codes and reviewing our protos to make sure we have an API that we can support for the life of containerd 1.x.
     8  
     9  # Image push
    10  
    11  We added a `push` and `push-object` command to the dist tool. The `push` command
    12  can be used to push a manifest and all the related objects to a registry. The
    13  `push-object` can push individual blobs from the content store to a registry.
    14  
    15  The push command does not require first tagging an image, just specify the
    16  remote name of the image as well as the local name. If the remote and local
    17  name are the same, only one argument is needed. The remote name may exclude
    18  the object identifier (Docker-style tag or digest), in which case the manifest
    19  may be repulled using the manifest digest as the object identifier. Push only
    20  handles pushing images which already exist, it will not create an image manifest
    21  if one does not exist. We will add a separate command for creating new images in
    22  the future.
    23  
    24  Example pushing image to a local registry.
    25  ```
    26  $ dist image list
    27  REF                               TYPE                                                 DIGEST                                                                  SIZE
    28  docker.io/library/ubuntu:latest   application/vnd.docker.distribution.manifest.v2+json sha256:382452f82a8bbd34443b2c727650af46aced0f94a44463c62a9848133ecb1aa8 44.7 MiB
    29  $ dist push localhost:5000/ubuntu docker.io/library/ubuntu:latest
    30  manifest-sha256:382452f82a8bbd34443b2c727650af46aced0f94a44463c62a9848133ecb1aa8: done           |++++++++++++++++++++++++++++++++++++++|
    31  layer-sha256:cf9722e506aada1109f5c00a9ba542a81c9e109606c01c81f5991b1f93de7b66:    done           |++++++++++++++++++++++++++++++++++++++|
    32  layer-sha256:b6f892c0043b37bd1834a4a1b7d68fe6421c6acbc7e7e63a4527e1d379f92c1b:    done           |++++++++++++++++++++++++++++++++++++++|
    33  layer-sha256:55010f332b047687e081a9639fac04918552c144bc2da4edb3422ce8efcc1fb1:    done           |++++++++++++++++++++++++++++++++++++++|
    34  layer-sha256:3deef3fcbd3072b45771bd0d192d4e5ff2b7310b99ea92bce062e01097953505:    done           |++++++++++++++++++++++++++++++++++++++|
    35  config-sha256:ebcd9d4fca80e9e8afc525d8a38e7c56825dfb4a220ed77156f9fb13b14d4ab7:   done           |++++++++++++++++++++++++++++++++++++++|
    36  layer-sha256:2955fb827c947b782af190a759805d229cfebc75978dba2d01b4a59e6a333845:    done           |++++++++++++++++++++++++++++++++++++++|
    37  elapsed: 6.5 s                                                                    total:  44.7 M (6.9 MiB/s)
    38  ```
    39  
    40  [#886 Add dist push-object](https://github.com/containerd/containerd/pull/886)
    41  
    42  [#911 Add dist push](https://github.com/containerd/containerd/pull/911)
    43  
    44  ## Client
    45  
    46  We started work on the initial containerd client.  Since we will have multiple consumers using the API, we want to reduce duplicated code for users of containerd.  Another goal for our client is to give users a stable client API that does not feel like they are working with a remote daemon.  Containers are already complex for most people but this does not need to be the case.  Building a platform on top of containerd should be effortless.  We want to handle the low level system aspects so that you can build a platform for your users and not worry about the underlying system, unless you want to.
    47  
    48  
    49  ### Creating a client for Docker
    50  
    51  ```go
    52  client, err := containerd.New(address, containerd.WithNamespace("docker"))
    53  if err != nil {
    54  	return err
    55  }
    56  defer client.Close()
    57  ```
    58  
    59  ### Pulling an Image from DockerHub
    60  
    61  ```go
    62  // pull && unpack the image to your snapshot ( overlayfs default ) of choice
    63  image, err := client.Pull(ctx, "docker.io/library/redis:alpine", containerd.WithPullUnpack)
    64  if err != nil {
    65  	return err
    66  }
    67  ```
    68  
    69  ### Generate an OCI runtime specification
    70  
    71  ```go
    72  // generate the spec based on the image that we pulled
    73  spec, err := containerd.GenerateSpec(containerd.WithImageConfig(ctx, image))
    74  if err != nil {
    75  	return err
    76  }
    77  ```
    78  
    79  ### Create a new container based on the image
    80  
    81  ```go
    82  // create the container with a persistent ReadWrite layer based on the image and spec
    83  container, err := client.NewContainer(ctx, "redis", spec, containerd.WithNewRootFS("redis-rootfs", image))
    84  if err != nil {
    85  	return err
    86  }
    87  defer container.Delete(ctx)
    88  ```
    89  
    90  ### Run the container
    91  
    92  ```go
    93  // use the current process's stdio
    94  task, err := container.NewTask(ctx, containerd.Stdio)
    95  if err != nil {
    96  	return err
    97  }
    98  defer task.Delete(ctx)
    99  
   100  pid := task.Pid()
   101  
   102  // start the redis process
   103  if err := task.Start(ctx); err != nil {
   104  	return err
   105  }
   106  
   107  task.Kill(ctx, syscall.SIGTERM)
   108  
   109  status, err := task.Wait(ctx)
   110  
   111  os.Exit(status)
   112  ```
   113  
   114  This is a very simple but common usecase for containerd.  Pull an image and run a container based on that image.  The client lets you write code, use `defer` statements and any other logic you want without having to do complex filesystem operations, deal with tar files or setting up root filesystems.  The API is split up and allows you to look into the lifecycle of an executing container without the need to register hooks and provide callbacks.
   115  
   116  Over the next few weeks we will be expanding the client to support the full containerd feature set.
   117  
   118  ## Testing
   119  
   120  With the initial client merged into the code base we are also starting work on integration tests.  We have full integration tests running on travis ci.  You don't have to mess with any other test frameworks to write tests for containerd, just the standard Go testing package.
   121  
   122  We also designed the client to allow mocking of calls so that our tests can be mocked out or users of our client to easily mock their own code for testing.
   123  
   124  You can view the PR [here](https://github.com/containerd/containerd/pull/910).
   125  
   126  
   127  ## What's Next?
   128  
   129  We still need to finish Events.  This is one of the last major features that we need before we consider containerd feature complete.  The namespace work is in progress with the initial service spec'd.
   130  
   131  Within the next few weeks we should have namespaces done, a complete client, and hopefully a stable events service.