Hello and welcome to this lecture.
My name is mugshot man I'm Beth and we are learning coordinators for beginners in this lecture.
We will talk about creating a pod using a demo based configuration file in the previous lecture.
We learn about e-mail files in general now we will learn how to develop e-mail files specifically for
Cuba.
Net is Cuban it is uses Jamil files as inputs for the creation of objects such as parts report cards
deployment services etc. All of these follow a similar structure.
Cuban errors definition file always contains four top level fields.
The API version kind metadata and spec.
These are the top level or root level properties.
These are also required fields so you must have them in your configuration file.
Let us look at each one of them.
The first one is the API abortion.
This is the version of the cobra that is API.
We are using to create the object depending on what we are trying to create.
We must use the right API version for now since we are working on parts.
We will set the EPA version as we 1.
Few other possible values for this field are apps for Slash p. 1 beta Extensions Plus 1 beta etc..
We will see what these are for later in this course next is the kind the kind refers to the type of
object we are trying to create which in this case happens to be a part.
So we will set it as part of some other possible values here.
Could be replica set or deployment or service which is what you see in the kind field in the table on
the right the next is metadata the metadata is data about the object like its name labels etc..
As you can see unlike the first two where you have specified a string value this is in the form of a
dictionary.
So everything under metadata is intended to the right a little bit and so names and labels are children
of metadata the number of spaces before the two properties name and labels doesn't matter but they should
be the same as they are siblings.
In this case labels has more spaces on the left than name and so it is now a child of the name property
instead of a sibling which is incorrect also the two properties must have more spaces than its parent
which is metadata so that it's intended to the right a little bit.
In this case all three of them have the same number of spaces before them and so they are all siblings
which is not correct.
Under metadata the name is a string value so you can name your part.
My app part and the labels is a dictionary so labels is a dictionary within the metadata dictionary.
And it can have any key and value pairs as you wish.
For now I have added a label app with the value my app.
Similarly you could add other labels as you see fit which will help you identify these objects at a
later point in time.
Say for example there are hundreds of parts running a front end application and hundreds of parts running
a back end application or a database.
It will be difficult for you to group these parts once they are deployed.
If you label them now as front end backend or database you will be able to filter the parts based on
this label at a later point in time.
It's important to note that under metadata you can only specify name or labels or anything else that
Coburn is expects to be under metadata.
You cannot add any other property as you wish under this.
However under the labels you can have any kind of key or value pairs as you see fit.
So it's important to understand what each of these parameters expect.
So far we have only mentioned the type and name of the object we need to create which happens to be
a pod with a name.
My app pod but we haven't really specified the container or image we need in the pod.
The last section in the configuration file is the specification section which is written as spec depending
on the object we are going to create.
This is where we would provide additional information to carbonate as pertaining to that object.
This is going to be different for different objects so it's important to understand or refer to the
documentation section to get the right format for each since we are only creating a pod with a single
container in it.
It is easy spec is a dictionary so add a property under it called containers containers is a list or
an array.
The reason this property is a list is because the parts can have multiple containers within them.
As we learned in the lecture earlier in this case though we will only add a single item in the list
since we plan to have only a single container in the pod.
The dash right before the name indicates that this is the first item in the list.
The item in the list is a dictionary.
So add a name and image property the value for image is in giant X which is the name of the Docker image
in the docker repository once the file is created from the command cube TTL create that f followed by
the file name which is part definition Don Hammel and Cuban artists creates the pod so to summarize
remember the four top level properties API version kind metadata and spec then start by adding values
to those depending on the object you are going to create once we create the part.
How do you see it use the cube.
Get parts.
Command to see a list of parts available.
In this case it's just one to see detailed information about the part.
Run the cube CDL describe port command.
This will tell you information about the part when it was created.
What labels are assigned to it.
What docker containers are a part of it and the events associated with that part.
That's it for this lecture.
We will now head over to a demo and I will see you in the next lecture.