[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Builds and Deployments can now reference image streams when running an integrated registry



Note - this change also tightened validation a on OpenShift resources to match Kubernetes conventions.  Names and namespaces must be lowercase letters or numbers with dashes, and names cannot exceed 63 characters in length.  A couple have folks have hit this already, apologies for not including it in the original email 


> On Jan 23, 2015, at 12:48 PM, Clayton Coleman <ccoleman redhat com> wrote:
> 
> Pull https://github.com/openshift/origin/pull/679 contained some fairly major changes to how images, builds, and deployments can be linked together.  It delivers the idea that image repositories are named ways of referencing a stream of images over time, by making it so that both builds and deployments can directly reference an image repository by name, and when that image repository gets updated, they'll trigger builds or deployments.
> 
> An example is in the sample-app now: https://github.com/openshift/origin/blob/5193072c5cd77d348dfbb6bf830e308d1f53ada3/examples/sample-app/application-template-stibuild.json
> 
> This image repository represents where an app goes:
> 
>    {
>      "metadata":{
>        "name": "origin-ruby-sample",
>      },
>      "kind": "ImageRepository",
>      "labels": {
>        "name": "origin-ruby-sample"
>      }
>    },
> 
> The build outputs directly to that image repository by name ("output.to"), and reads from the ruby-20-centos image repository as well by name ("triggers[0].imageChange.from")
> 
>    {
>      "metadata":{
>        "name": "ruby-sample-build",
>      },
>      "kind": "BuildConfig",
>      "triggers": [
>        {
>          "type": "imageChange",
>          "imageChange": {
>            "image": "openshift/ruby-20-centos",
>            "from": { 
>              "name": "ruby-20-centos"
>            },
>            "tag":"latest"
>          }
>        }
>      ],
>      "parameters": {
>        ...
>        "output": {
>          "to": {
>            "name": "origin-ruby-sample"
>          }
>        },
>      },
>      "labels": {
>        "name": "ruby-sample-build"
>      }
>    },
> 
> The deployment config does the same thing - it triggers based on "origin-ruby-sample" via the "from" field:
> 
>    {
>      "metadata":{
>        "name": "frontend",
>      },
>      "kind": "DeploymentConfig",
>      "triggers": [
>        {
>          "type": "ImageChange",
>          "imageChangeParams": {
>            "automatic": true,
>            "containerNames": [
>              "ruby-helloworld"
>            ],
>            "from": {
>              "name": "origin-ruby-sample"
>            },
>            "tag": "latest"
>          }
>        }
>      ],
>      ...
>    }
> 
> Note that DeploymentConfig and BuildConfig have different names for their trigger parameters, and that's something we'll fix in the next API version.
> 
> When the example installs the default registry (as docker-registry), it's *automatically* linked up so that when you push an image to "<defaultRegistry>/test/origin-ruby-sample" via Docker, the image repository called "origin-ruby-sample" in the "test" namespace is updated.  As the integration with the registry gets better, there will be access control and security around those image repositories based on your project.  It's not quite there yet.  The end goal though is that as a user, you can create an ImageRepository, give it your own name, and then either push images there (set up automatically) or have it poll the contents of another repository.  Then your builds and deployments are decoupled from an individual docker registry, and you can switch which images you're using without having to redo your builds or deployments.  This flexibility is key - our generation code will let you link these flows together across projects, so operations can deploy images to an entire organization, but each application or project can react as they need.
> 
> Existing Builds and DeploymentConfigs should be unaffected (we support the old behavior via backwards API compatibility) but if you hit any problems please let me know and we'll get it fixed.
> 
> Thanks!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]