The image in the deployment yaml is in the below format :
'${DockerRegistry}/${orgName}/${projectName}/${ImageName}:${version}'
There are 3 forward slashes in the image name after the docker registry name and this is causing an error. I tried with Kubernetes plugin of 16, 17, 18 & 19 and Process Yaml step of Kubernetes is throwing the below error.
Loading /opt/ibm-ucd/agent/var/work/lr-central-credit-register/common/openshift/dc.yml The desired versions for existing image components is [:] Creating ibm-ucd-kubernetes.yaml Creating component: cbrpoc-loan-requests-cbrpoc-loan-requests/lr-central-credit-register Caught: java.io.IOException: 400 Error processing command: Name cannot contain the following characters: / \ [ ] % java.io.IOException: 400 Error processing command: Name cannot contain the following characters: / \ [ ] % at com.urbancode.ud.client.UDRestClient.invokeMethod(UDRestClient.java:225) at com.urbancode.ud.client.ComponentClient.createComponent(ComponentClient.java:180) at processyaml.createComponent(processyaml.groovy:481) at processyaml.this$4$createComponent(processyaml.groovy) at processyaml$_run_closure6.doCall(processyaml.groovy:362) at processyaml.run(processyaml.groovy:325)
According to the official documentation of Docker Registry HTTP API V2
A repository name is broken up into path components. A component of a
repository name must be at least one lowercase, alpha-numeric
characters, optionally separated by periods, dashes or underscores.
More strictly, it must match the regular expression
[a-z0-9]+(?:[._-][a-z0-9]+)*. If a repository name has two or more
path components, they must be separated by a forward slash (“/”). The
total length of a repository name, including slashes, must be less
than 256 characters.
Please make sure you are using Docker Registry HTTP API V2 and follow all the above rules.
While the V1 registry protocol is usable, there are several problems with the architecture that have led to V2.
Additionally, you can try to use Docker Tag
Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
More info with examples lined above.
Please let me know if that helped.
Related
I am looking at the stackstorm docker-compose file, and within it almost all containers have a line dns_search: . According to docker-compose documentation, dns_search is for the purpose of configuring search domains.
I am used to seeing this in context of transparently adding a domain to unqualified short domains. For example if I add dns_search: mydomain.com, I would expect "host1" to transparently resolve as "host1.mydomain.com".
I have never seen this set as a single dot . before. What is the effect/purpose of doing this configuration?
I'm posting the answer from the Stackstorm Git project issue see comment/"dns_search: .". Paraphrasing: it was useful in old versions of Docker before 2017, before the ndots configuration was available. Nowadays that configuration has no impact, and in fact has been removed from the stackstorm docker-compose file.
I believe this is because all domain names end in . under the hood, but browsers and other software abstracts this out.
For example. under the hood www.google.com is actually www.google.com.
So, in the docker-compose file, this would essentially be saying "Find me any domain"
A bit more detail on why there's an extra dot, if you're interested:
Domain name resolution is heirachical, reading right to left, with each block, separated by a ., being a step in the process. A DNS resolver will first find a source of ., which will be able to return the address for a resolver for the next block, until it reaches the final block, where it returns the full DNS record.
Extending EdwardTeach's answer:
#ytjohn effectively said they did in the past because putting dns_search: . configures the DNS search domains to be only . instead of inheriting the host ones. I can't confirm that because I didn't test it.
Now, I tested what docker-compose does today, and in a container, cat /etc/resolve.conf returns:
nameserver 127.0.0.11
options ndots:0
Where options ndots:0 is (from resolv.conf docs):
ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will
be made. The default for n is 1, meaning that if
there are any dots in a name, the name will be
tried first as an absolute name before any search
list elements are appended to it. The value for
this option is silently capped to 15.
With ndots:0, all domains will be attempted using the absolute name first, only then using the search list.
How I came to this conclusion
The Github comment:
If you don't set this dns_search: ., then whatever the host has in search in their /etc/resolv.conf will get put into your container's /etc/resolv.conf.
This doesn't happen. My host has search domain[0]: broadband (macOS command: scutil --dns), and in docker containers, it doesn't show broadband (linux command: cat /etc/resolv.conf). Instead, it says options ndots:0
dns_search docs:
dns defines custom DNS search domains to set on container network interface configuration. Can be a single value or a list.
What is a DNS search domain?
It is the DNS service used to resolve hostnames that are not fully qualified, e.g. hostname will try hostname.example.com then hostname.website.com if your search domains list was example.com, website.com. More information on https://superuser.com/a/184366
In another repo (crossdock), their dockerfile had the comment:
`dns_search: . # Ensures unified DNS config.`
A team I'm working with, has created a NAS Docker container. The Dockerfile uses FROM synadia/nats-account-server:0.8.4 and installs NSC using curl -L https://raw.githubusercontent.com/nats-io/nsc/master/install.py | python. When NAS is run in the Docker container, it is given a path to a server.conf file that contains operatorjwtpath: "/nsc/accounts/nats/OperatorName/OperatorName.jwt".
The problem is, that when I generate the operator on my PC using nsc add operator -i and when I run the Docker container on AWS Fargate and mount the JWT file to the appropriate folder using an AWS EFS filesystem, the container crashes and shows the error unexpected "ed25519-nkey" algorithm.
According to the NATS basics page, the algorithm that should be used is "alg": "ed25519". But when I generated the JWT and decoded it on this site, I see that what's being used is "alg": "ed25519-nkey".
So what is going on here? I can't find any specific info about an algorithm that has the "nkey" appended to its name. This is the default JWT that's generated. Why is it different from what the NAS algorithm expects? How do I solve this error?
Extra info: According to this site, it's supposed to be due to a version conflict, but even upgrading to FROM synadia/nats-account-server:1.0.0 didn't solve it.
I need to issue a command "python manage.py rebuild_index" for rebuilding index of apache solr in my app deployment. But i get the following error:
The Deployment "test-app" is invalid: spec.template.spec.initContainers[5].name: Invalid value: "rebuild_index": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')
As per your error message I don't think the error is due to '_' in command, I guess you have named initContainers name as well "rebuild_index" that is where the error has been generated.
Object Name in k8s should be an alphanumeric character where only "." and "-" special characters are allowed. You can read more on this documentation link. Please change the initContainer name to "rebuild-index" which will resolve your issue.
Thanks,
I am using the docker image version of Fiware Orion. When I try to delete entities using a service path ending # I received a 204 but the entity is not erased.
I tried with the next service paths for a \test\testa entity:
/#
/test/#
/test/testa/#
Hierarchical search (using # suffix) or multipath search (using several service path separated by comma) is only allowed in query requests. For update requests only single and not hierarchical service paths are allowed.
Delete entity is a kind of update request, so you cannot use the # suffix.
I am trying to add a MongoDB cluster as part of a Serverless deployment, but I can't set the environment variable.
Here is part of the serverless.yml file:
service: serverless-test
plugins:
- serverless-offline
provider:
name: aws
runtime: nodejs4.3
environment:
MONGO_URI: "mongodb://mongo-6:27000,mongo-7:27000,mongo-8:27000/db-dev?replicaSet=mongo"
How do I pass the MONGO_URI to contain the cluster as a comma separated value?
Any advise is much appreciated.
Unfortunately, you can't use commas in Lambda environment variables. This is an AWS limitation and not a Serverless issue.
For example, browse the AWS console and try to add a environment variable that contains a comma:
When you save, you will get the following error:
1 validation error detected: Value at 'environment.variables' failed to satisfy constraint: Map value must satisfy constraint: [Member must satisfy regular expression pattern: [^,]*]
The error message says that the regex [^,]* must be satisfied and what this small regex explicitly says is to not (^) accept the comma (,). Any other char is acceptable.
I don't know why they don't accept the comma and this is not explained in their documentation, but at least their error message shows that it is intentional.
As a workaround, you can replace your commas by another symbol (like #) to create the env var and replace it back to comma after reading the variable, or you will need to create multiple env vars to store the endpoints.