How exactly is expected to be created and validated signed manifest for a Docker container using schema v1?
The documentation shows an example of a signed manifest file, like the one shown below:
{
"name": "hello-world",
"tag": "latest",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
}
],
"history": [
{
"v1Compatibility": ".."
}
],
"schemaVersion": 1,
"signatures": [
{
"header": {
"jwk": {
"crv": "P-256",
"kid": "OD6I:6DRK:JXEJ:KBM4:255X:NSAA:MUSF:E4VM:ZI6W:CUN2:L4Z6:LSF4",
"kty": "EC",
"x": "3gAwX48IQ5oaYQAYSxor6rYYc_6yjuLCjtQ9LUakg4A",
"y": "t72ge6kIA1XOjqjVoEOiPPAURltJFBMGDSQvEGVB010"
},
"alg": "ES256"
},
"signature": "XREm0L8WNn27Ga_iE_vRnTxVMhhYY0Zst_FfkKopg6gWSoTOZTuW4rK0fg_IqnKkEKlbD83tD46LKEGi5aIVFg",
"protected": "eyJmb3JtYXRMZW5ndGgiOjY2MjgsImZvcm1hdFRhaWwiOiJDbjAiLCJ0aW1lIjoiMjAxNS0wNC0wOFQxODo1Mjo1OVoifQ"
}
]
}
It's mentioned that the signature can be generated using trustlib, however, it's not clear how. Is there any code example or even better a CLI tool that can be used to sign and validate a manifest as the one above?
Related
I need to get the image upload date from a Docker Registry
I currently use the following https://registry/v2/repository/manifests/tag which gives me Creation Date. This is stale in most cases. I want to know when something was uploaded.
If I can't get this, is there a way to do docker build and specify and date/time which could be used in place of the Creation Date?
An example of the manifest I'm getting which shows the only dates available are the v1Compatibility/created:
{
"schemaVersion": 1,
"name": "users/jesaremi/baseimage",
"tag": "6a69f60507f029f76ff102aa1b89b562d2d784dfdbfef38cb0ed5c0b61a188ff",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
},
{
"blobSum": "sha256:7c9d20b9b6cda1c58bc4f9d6c401386786f584437abbe87e58910f8a9a15386b"
}
],
"history": [
{
"v1Compatibility": "{\"architecture\":\"amd64\",\"config\":{\"Hostname\":\"\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":[\"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\"],\"Cmd\":[\"sh\"],\"ArgsEscaped\":true,\"Image\":\"sha256:758a17a836a4c09586a291c928d1f0561320e252d07c4749e14338daefe84b18\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":null},\"container\":\"e30cd53834b3dfdb989c63cc73f4f31f404c7a6a0c0e9d6b9e3e8451edd72596\",\"container_config\":{\"Hostname\":\"e30cd53834b3\",\"Domainname\":\"\",\"User\":\"\",\"AttachStdin\":false,\"AttachStdout\":false,\"AttachStderr\":false,\"Tty\":false,\"OpenStdin\":false,\"StdinOnce\":false,\"Env\":[\"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\"],\"Cmd\":[\"/bin/sh\",\"-c\",\"#(nop) \",\"CMD [\\\"sh\\\"]\"],\"ArgsEscaped\":true,\"Image\":\"sha256:758a17a836a4c09586a291c928d1f0561320e252d07c4749e14338daefe84b18\",\"Volumes\":null,\"WorkingDir\":\"\",\"Entrypoint\":null,\"OnBuild\":null,\"Labels\":{}},\"created\":\"2019-09-04T19:20:16.230463098Z\",\"docker_version\":\"18.06.1-ce\",\"id\":\"a91ec18e2f45c300f1df0a23ac04c1396d791c6c387dd5e16e44dc96a4fc309d\",\"os\":\"linux\",\"parent\":\"bd5fbbc2870744fe1d37bbd120eebe4c441f8401c54b04b8ae0f9f625936f4c3\",\"throwaway\":true}"
},
{
"v1Compatibility": "{\"id\":\"bd5fbbc2870744fe1d37bbd120eebe4c441f8401c54b04b8ae0f9f625936f4c3\",\"created\":\"2019-09-04T19:20:16.080265634Z\",\"container_config\":{\"Cmd\":[\"/bin/sh -c #(nop) ADD file:9151f4d22f19f41b7a289e87aa9cfba3956ffd27746cb3b171b9bd2cb7e6c313 in / \"]}}"
}
],
"signatures": [
{
"header": {
"jwk": {
"crv": "P-256",
"kid": "3NQM:K5YD:M3XF:EKJD:4S64:3772:BJOT:JIMR:NX4R:2XYS:IDNA:NOKL",
"kty": "EC",
"x": "k6pZfyr-dKYLri5KJCL70UmNLCQnfUh2lAC_nDK9PVw",
"y": "MhrKOUbx1sgsbF0kG9d5bfvkVaxaFWiKlWTwgFyHkbQ"
},
"alg": "ES256"
},
"signature": "klE8-cWOS1GZenBB7CPXYUK8VWmqiVQaFfWGgBQPn_L8iayojGEUc9D_06WCUdAqL7upvNIxcCPXJvZMORLn_Q",
"protected": "eyJmb3JtYXRMZW5ndGgiOjIxOTksImZvcm1hdFRhaWwiOiJDbjAiLCJ0aW1lIjoiMjAxOS0xMC0yM1QyMTo0MTozM1oifQ"
}
]
}
I am using kubernetes : v1.10.3 , i have one external NFS server which i am able to mount anywhere ( any physical machines). I want to mount this NFS directly to pod/container . I tried but every time i am getting error. don't want to use privileges, kindly help me to fix.
ERROR: MountVolume.SetUp failed for volume "nfs" : mount failed: exit
status 32 Mounting command: systemd-run Mounting arguments:
--description=Kubernetes transient mount for /var/lib/kubelet/pods/d65eb963-68be-11e8-8181-00163eeb9788/volumes/kubernetes.io~nfs/nfs
--scope -- mount -t nfs 10.225.241.137:/stagingfs/alt/ /var/lib/kubelet/pods/d65eb963-68be-11e8-8181-00163eeb9788/volumes/kubernetes.io~nfs/nfs
Output: Running scope as unit run-43393.scope. mount: wrong fs type,
bad option, bad superblock on 10.225.241.137:/stagingfs/alt/, missing
codepage or helper program, or other error (for several filesystems
(e.g. nfs, cifs) you might need a /sbin/mount. helper program)
In some cases useful info is found in syslog - try dmesg | tail or so.
NFS server : mount -t nfs 10.X.X.137:/stagingfs/alt /alt
I added two things for volume here but getting error every time.
first :
"volumeMounts": [
{
"name": "nfs",
"mountPath": "/alt"
}
],
Second :
"volumes": [
{
"name": "nfs",
"nfs": {
"server": "10.X.X.137",
"path": "/stagingfs/alt/"
}
}
],
---------------------complete yaml --------------------------------
{
"kind": "Deployment",
"apiVersion": "extensions/v1beta1",
"metadata": {
"name": "jboss",
"namespace": "staging",
"selfLink": "/apis/extensions/v1beta1/namespaces/staging/deployments/jboss",
"uid": "6a85e235-68b4-11e8-8181-00163eeb9788",
"resourceVersion": "609891",
"generation": 2,
"creationTimestamp": "2018-06-05T11:34:32Z",
"labels": {
"k8s-app": "jboss"
},
"annotations": {
"deployment.kubernetes.io/revision": "2"
}
},
"spec": {
"replicas": 1,
"selector": {
"matchLabels": {
"k8s-app": "jboss"
}
},
"template": {
"metadata": {
"name": "jboss",
"creationTimestamp": null,
"labels": {
"k8s-app": "jboss"
}
},
"spec": {
"volumes": [
{
"name": "nfs",
"nfs": {
"server": "10.X.X.137",
"path": "/stagingfs/alt/"
}
}
],
"containers": [
{
"name": "jboss",
"image": "my.abc.com/alt:7.1_1.1",
"resources": {},
"volumeMounts": [
{
"name": "nfs",
"mountPath": "/alt"
}
],
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"imagePullPolicy": "IfNotPresent",
"securityContext": {
"privileged": true
}
}
],
"restartPolicy": "Always",
"terminationGracePeriodSeconds": 30,
"dnsPolicy": "ClusterFirst",
"securityContext": {},
"schedulerName": "default-scheduler"
}
},
"strategy": {
"type": "RollingUpdate",
"rollingUpdate": {
"maxUnavailable": "25%",
"maxSurge": "25%"
}
},
"revisionHistoryLimit": 10,
"progressDeadlineSeconds": 600
},
"status": {
"observedGeneration": 2,
"replicas": 1,
"updatedReplicas": 1,
"readyReplicas": 1,
"availableReplicas": 1,
"conditions": [
{
"type": "Available",
"status": "True",
"lastUpdateTime": "2018-06-05T11:35:45Z",
"lastTransitionTime": "2018-06-05T11:35:45Z",
"reason": "MinimumReplicasAvailable",
"message": "Deployment has minimum availability."
},
{
"type": "Progressing",
"status": "True",
"lastUpdateTime": "2018-06-05T11:35:46Z",
"lastTransitionTime": "2018-06-05T11:34:32Z",
"reason": "NewReplicaSetAvailable",
"message": "ReplicaSet \"jboss-8674444985\" has successfully progressed."
}
]
}
}
Regards
Anupam Narayan
As stated in the error log:
for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount. helper program
According to this question, you might be missing the nfs-commons package which you can install using sudo apt install nfs-common
I have linked a Persistent Volume to my Kubernetes Neo4j Replication Controller to store the DB data. Now I would like to download that data locally to run the production DB on my system. I can't find the way to download the Disk content. Can someone point me in the right direction?
Updates (Persistent Volume Creation with Kubernetes):
persistent-volume-db.json
{
"kind": "PersistentVolume",
"apiVersion": "v1",
"metadata": {
"name": "pv-db"
},
"spec": {
"capacity": {
"storage": "500Gi"
},
"accessModes": [
"ReadWriteMany"
],
"gcePersistentDisk": {
"pdName": "tuwa-db-data-disk",
"fsType": "ext4"
}
}
}
persistent-volume-claim-db.json
{
"kind": "PersistentVolumeClaim",
"apiVersion": "v1",
"metadata": {
"name": "pvc"
},
"spec": {
"accessModes": [
"ReadWriteMany"
],
"resources": {
"requests": {
"storage": "500Gi"
}
}
}
}
And then the usage:
neo4j-controller.json
{
"kind": "ReplicationController",
"apiVersion": "v1",
"metadata": {
"name": "neo4j-controller",
"labels": {
"name": "neo4j"
}
},
"spec": {
"replicas": 1,
"template": {
"metadata": {
"labels": {
"name": "neo4j"
}
},
"spec": {
"containers": [
{
"name": "neo4j",
"image": "neo4j/neo4j",
"ports": [
{
"name": "neo4j-server",
"containerPort": 7474
}
],
"volumeMounts": [
{
"mountPath": "/data/databases",
"name": "pv-db"
}
]
}
],
"volumes": [
{
"name": "pv-db",
"persistentVolumeClaim": {
"claimName": "pvc-db"
}
}
]
}
}
}
}
GCE's admin panel doesn't have a "download" button for persistent disks, but gcloud makes it easy to copy files from an instance to your local machine:
gcloud compute copy-files example-instance:~/REMOTE-DIR ~/LOCAL-DIR --zone us-central1-a
This will copy ~/REMOTE-DIR from a remote instance into ~/LOCAL-DIR on your machine. Just replace the directory names, example-instance with your instances name, and adjust your zone if necessary. More info here in the docs.
gcloud compute copy-files #has been deprecated
Please use gcloud compute scp instead. Note that gcloud compute scp does not have recursive copy on by default. To turn on recursion, use the --recurse flag.
gcloud compute scp --recurse example-instance:~/instance-1_path ~/locad_path --zone=us-central1-a
This will copy ~/instance-1_path from a remote compute instance into ~/local_path on your personal machine. Just replace the directory names, example-instance with your instances name, and adjust your zone if necessary.
Complete documentation of this SDK can be found here
Can someone give an example of how to use the gitRepo type of volume in Kubernetes?
The doc says it's a plugin, not sure what that means. Could not find an example anywhere and i don't know the proper syntax.
especially is there parameters to pull a specific branch, use credentials (username, password, or SSH key) etc...
EDIT:
Going through the Kubernetes code this is what I figured so far:
- name: data
gitRepo:
repository: "git repo url"
revision: "hash of the commit to use"
But can't seen to make it work, and not sure how to troubleshoot this issue
This is a sample application I used:
{
"kind": "ReplicationController",
"apiVersion": "v1",
"metadata": {
"name": "tess.io",
"labels": {
"name": "tess.io"
}
},
"spec": {
"replicas": 3,
"selector": {
"name": "tess.io"
},
"template": {
"metadata": {
"labels": {
"name": "tess.io"
}
},
"spec": {
"containers": [
{
"image": "tess/tessio:0.0.3",
"name": "tessio",
"ports": [
{
"containerPort": 80,
"protocol": "TCP"
}
],
"volumeMounts": [
{
"mountPath": "/tess",
"name": "tess"
}
]
}
],
"volumes": [
{
"name": "tess",
"gitRepo": {
"repository": "https://<TOKEN>:x-oauth-basic#github.com/tess/tess.io"
}
}
]
}
}
}
}
And you can use the revision too.
PS: The repo above does not exist anymore.
UPDATE:
gitRepo is now deprecated
https://github.com/kubernetes/kubernetes/issues/60999
ORIGINAL ANSWER:
going through the code this is what i figured:
- name: data
gitRepo:
repository: "git repo url"
revision: "hash of the commit to use"
after fixing typos in my mountPath, it works fine.
I'm working with mesos + marathon + docker quite a while but I got stuck at some point. At the moment I try to deal with persistent container and I tried to play around with the "volumes-from" parameter but I can't make it work because I have no clue how I can figure out the name of the data box to put it as a key in the json. I tried it with the example from here
{
"id": "privileged-job",
"container": {
"docker": {
"image": "mesosphere/inky"
"privileged": true,
"parameters": [
{ "key": "hostname", "value": "a.corp.org" },
{ "key": "volumes-from", "value": "another-container" },
{ "key": "lxc-conf", "value": "..." }
]
},
"type": "DOCKER",
"volumes": []
},
"args": ["hello"],
"cpus": 0.2,
"mem": 32.0,
"instances": 1
}
I would really appreciate any kind of help :-)
From what I know :
docker --volume-from take the ID or the name of a container.
Since your datacontainer is launch with Marathon too, it get an ID (not sur how to get this ID from marathon) and a name of that form : mesos-0fb2e432-7330-4bfe-bbce-4f77cf382bb4 which is not related to task ID in Mesos nor docker ID.
The solution would be to write something like this for your web-ubuntu application :
"parameters": [
{ "key": "volumes-from", "value": "mesos-0fb2e432-7330-4bfe-bbce-4f77cf382bb4" }
]
Since this docker-ID is unknown from Marathon it is not practical to use datacontainer that are started with Marathon.
You can try to start a datacontainer directly with Docker (without using Marathon) and use it as you do before but since you don't know in advance where web-ubuntu will be scheduled (unless you add a constraint to force it) it is not practical.
{
"id": "data-container",
"container": {
"docker": {
"image": "mesosphere/inky"
},
"type": "DOCKER",
"volumes": [
{
"containerPath": "/data",
"hostPath": "/var/data/a",
"mode": "RW"
}
]
},
"args": ["data-only"],
"cpus": 0.2,
"mem": 32.0,
"instances": 1
}
{
"id": "privileged-job",
"container": {
"docker": {
"image": "mesosphere/inky"
"privileged": true,
"parameters": [
{ "key": "hostname", "value": "a.corp.org" },
{ "key": "volumes-from", "value": "data-container" },
{ "key": "lxc-conf", "value": "..." }
]
},
"type": "DOCKER",
"volumes": []
},
"args": ["hello"],
"cpus": 0.2,
"mem": 32.0,
"instances": 1
}
Something like that maybe?
Mesos support passing the parameter of volume plugin using "key" & "value". But the issue is how to pass the volume name which Mesos expects to be either an absolute path or if absolute path is not passed then it will merge the name provided with the slave container sandbox folder. They do that primarily to support checkpointing, in case slave goes down accidentally.
The only option, till the above get enhanced, is to use another key value pair parameter. For e.g. in above case
{ "key": "volumes-from", "value": "databox" },
{ "key": "volume", "value": "datebox_volume" }
I have tested above with a plugin and it works.
Another approach is to write a custom mesos framework capable of running the docker command you want. In order to know what offers to accept and where to place each task you can use marathon information from: /apps/v2/ (under tasks key).
A good starting point for writing a new mesos framework is: https://github.com/mesosphere/RENDLER