I am running latest version of SCDF server on Kubernetes cluster. Every time I try to run a composed task, it tries to fetch the application properties for composed-task-runner application and fails to launch the composed task.
First of all, SCDf is trying to pull the properties (metadata) from Spring Maven repo when I am running the server on k8s. my server behind a firewall and it cannot connect to spring maven repo. I already downloaded the composed-task-runner docker image to my local repo and added the composed-task-runner application using UI. Why it still tries to download metadata from Spring Maven repo ? How do I stop it ?
here is the log :
2020-11-21 15:49:07.591 INFO 1 --- [nio-8080-exec-4] o.s.c.d.s.k.DefaultContainerFactory : Using Docker entry point style: exec
2020-11-21 15:49:58.355 WARN 1 --- [nio-8080-exec-6] .s.c.d.s.s.i.TaskConfigurationProperties : org.springframework.cloud.dataflow.server.service.impl.TaskConfigurationProperties.logDeprecationWarning is deprecated. Please use org.springframework.cloud.dataflow.server.service.impl.ComposedTaskRunnerConfigurationProperties.logDeprecationWarning
2020-11-21 15:50:18.427 WARN 1 --- [nio-8080-exec-6] ApplicationConfigurationMetadataResolver : Failed to retrieve properties for resource org.springframework.cloud:spring-cloud-dataflow-composed-task-runner:jar:2.7.0-SNAPSHOT because of ConnectTimeoutException: Connect to repo.spring.io:443 timed out
2020-11-21 15:50:38.522 WARN 1 --- [nio-8080-exec-6] ApplicationConfigurationMetadataResolver : Failed to retrieve properties for resource org.springframework.cloud:spring-cloud-dataflow-composed-task-runner:jar:2.7.0-SNAPSHOT because of ConnectTimeoutException: Connect to repo.spring.io:443 timed out
2020-11-21 15:50:38.572 INFO 1 --- [nio-8080-exec-6] o.s.c.d.s.k.KubernetesTaskLauncher : Preparing to run a container from org.springframework.cloud:spring-cloud-dataflow-composed-task-runner:jar:2.7.0-SNAPSHOT. This may take some time if the image must be downloaded from a remote container registry.
2020-11-21 15:50:38.573 INFO 1 --- [nio-8080-exec-6] o.s.c.d.s.k.DefaultContainerFactory : Using Docker image: //org.springframework.cloud:spring-cloud-dataflow-composed-task-runner:jar:2.7.0-SNAPSHOT
Looks like, the Composed Task Runner docker image can now be set using the environment variable :
name: SPRING_CLOUD_DATAFLOW_TASK_COMPOSED_TASK_RUNNER_URI
value: 'docker://springcloud/spring-cloud-dataflow-composed-task-runner:2.6.0'
We were on SCDF server 2.2.4 version before this and we had to manually add the composed task runner as an Application using the dashboard UI.
Right now, all I had to do is to download this image and push to my local git repo and use it here.
Related
I have an legacy application that uses websphere application server 9.0.0 , I want to containerize it using docker, but I am putting the message on MQ , it is giving me below error:
Unwrapping Non-DiagnosticException:
Exception Type : com.ibm.msg.client.jms.DetailedJMSException
Exception Message: JMSWMQ0018: Failed to connect to queue manager 'MQGWD2' with connection mode 'Client' and host name 'mqgwd2.sdde.deere.com(2171)'.
Begin Stack Trace:
com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'MQGWD2' with connection mode 'Client' and host name 'mqgwd2.sdde.deere.com(2171)'.
Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:595)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:424)
at com.ibm.msg.client.wmq.internal.WMQXAConnection.<init>(WMQXAConnection.java:67)
at com.ibm.msg.client.wmq.factories.WMQXAConnectionFactory.createV7ProviderConnection(WMQXAConnectionFactory.java:187)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:7810)
at com.ibm.msg.client.wmq.factories.WMQXAConnectionFactory.createProviderXAConnection(WMQXAConnectionFactory.java:98)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createXAConnectionInternal(JmsConnectionFactoryImpl.java:390)
at com.ibm.mq.jms.MQXAQueueConnectionFactory.createXAQueueConnection(MQXAQueueConnectionFactory.java:154)
My docker-compose.yml looks like:
version: "3.9"
services:
consolidated:
build: .
ports:
- "9043:9043"
- "9443:9443"
- "9083:9083"
To run this application without container, I didn't install any MQ separately, I am just using the one the is there already in websphere server, the same doesn't work with the containerized image. I have compared all the connection factories through admin console and they are looking ok. The same configuration works on non-containerized version of this application
I'm using SCDF 2.6.1 in Openshift 3, and I'm facing error while registering the app, error log like below :
java.lang.NullPointerException: null
at org.springframework.cloud.dataflow.configuration.metadata.container.DefaultContainerImageMetadataResolver.getRegistryRequest(DefaultContainerImageMetadataResolver.java:162)
at org.springframework.cloud.dataflow.configuration.metadata.container.DefaultContainerImageMetadataResolver.getImageLabels(DefaultContainerImageMetadataResolver.java:110)
at org.springframework.cloud.dataflow.configuration.metadata.BootApplicationConfigurationMetadataResolver.resolvePortNamesFromContainerImage(BootApplicationConfigurationMetadataResolver.java:215)
at org.springframework.cloud.dataflow.configuration.metadata.BootApplicationConfigurationMetadataResolver.listPortNames(BootApplicationConfigurationMetadataResolver.java:163)
at org.springframework.cloud.dataflow.server.controller.AppRegistryController.getInfo(AppRegistryController.java:193)
at org.springframework.cloud.dataflow.server.controller.AppRegistryController.info(AppRegistryController.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I checked the line of code in DefaultContainerImageMetadataResolver.java:162
// Convert the image name into a well-formed ContainerImage
ContainerImage containerImage = this.containerImageParser.parse(imageName);
// Find a registry configuration that matches the image's registry host
RegistryConfiguration registryConf = this.registryConfigurationMap.get(containerImage.getRegistryHost());
// Retrieve a registry authorizer that supports the configured authorization type.
RegistryAuthorizer registryAuthorizer = this.registryAuthorizerMap.get(registryConf.getAuthorizationType());
I'm pretty sure the error is because registryConf is null as result from
RegistryConfiguration registryConf = this.registryConfigurationMap.get(containerImage.getRegistryHost());
How to put my private repo URI in registryConfigurationMap ?
I have tried to put imagePullSecret in the deployment.yml which is registered with the private repo, but I think it doesn't work because in the startup log, I still see :
2020-09-03 04:55:24.111 INFO 1 --- [ main] urationMetadataResolverAutoConfiguration :
Final Registry Configurations: {registry-1.docker.io=RegistryConfiguration{registryHost='registry-1.docker.io', user='null', secret='****'', authorizationType=dockeroauth2, manifestMediaType='application/vnd.docker.distribution.manifest.v2+json', disableSslVerification='false',
extra={registryAuthUri=https://auth.docker.io/token?service=registry.docker.io&scope=repository:{repository}:pull&offline_token=1&client_id=shell }}}
The only place where SCDF server downloads the container image layer is when it looks for app metadata.
Currently, this is configured to use the docker registry host (as this is where all the out-of-the-box applications are hosted).
If you want to override, you can modify these property values at the time of server startup and proceed.
Remember the fact that this configuration is only needed to download the app metadata layer of the image - not to download the entire container image at the SCDF server side.
I've been trying to setup Cloud Code with VSCode and I've been running in to problems when starting the deploy process with Cloud Code: Deploy.
I've tried deploying the samples, python-hello-world-1 as well as the go-hello-world-1, to my kubernetes cluster on GKE but always end up getting errors when the deploy process starts package downloading:
Go Output
Running: skaffold run --enable-rpc -v info --rpc-http-port 49869 --filename skaffold.yaml --default-repo gcr.io/abx-lernende
starting gRPC server on port 50051
starting gRPC HTTP server on port 49869
Using kubectl context: gke_abx-lernende_europe-west4-a_joshu-test-cluster
Generating tags...
- go-hello-world -> gcr.io/abx-lernende/go-hello-world:latest
Checking cache...
- go-hello-world: Not found. Building
Building [go-hello-world]...
Sending build context to Docker daemon 57.86kB
Step 1/8 : FROM golang:1.13
---> 6586e3d10e96
Step 2/8 : RUN go get -u -v github.com/go-delve/delve/cmd/dlv
---> Running in b75ce8e5dae9
[91mgithub.com/go-delve/delve (download)
[0m[91m# cd .; git clone -- https://github.com/go-delve/delve /go/src/github.com/go-delve/delve
Cloning into '/go/src/github.com/go-delve/delve'...
fatal: unable to access 'https://github.com/go-delve/delve/': Failed to connect to github.com port 443: Connection refused
package github.com/go-delve/delve/cmd/dlv: exit status 128
[0mfailed to build: build failed: building [go-hello-world]: build artifact: unable to stream build output: The command '/bin/sh -c go get -u -v github.com/go-delve/delve/cmd/dlv' returned a non-zero code: 1
Exited with code 1.
Python Output
Running: skaffold run --enable-rpc -v info --rpc-http-port 50185 --filename
skaffold.yaml --default-repo gcr.io/abx-lernende
starting gRPC server on port 50051
starting gRPC HTTP server on port 50185
Skaffold &{Version:v1.3.1 ConfigVersion:skaffold/v2alpha3 GitVersion: GitCommit:6ba887a42438d1da578a005cf550e618fee6dfb8 GitTreeState:clean BuildDate:2020-01-31T19:55:18Z GoVersion:go1.13.4 Compiler:gc Platform:windows/amd64}
Using kubectl context: gke_abx-lernende_europe-west4-a_joshu-test-cluster
Generating tags...
- python-hello-world -> Tags generated in 0s
gcr.io/abx-lernende/python-hello-world:latest
Checking cache...
- python-hello-world: Cache check complete in 6.0001ms
Not found. Building
Building [python-hello-world]...
Sending build context to Docker daemon 4.608kB
Step 1/7 : FROM python:3.8
---> efdecc2e377a
Step 2/7 : WORKDIR /app
---> Using cache
---> a131b81cad66
Step 3/7 : COPY requirements.txt .
---> Using cache
---> 4625ef1862bd
Step 4/7 : RUN pip install --trusted-host pypi.python.org -r requirements.txt
---> Running in 4da23a158ae3
[91mWARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f17ba9c9d60>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/flask/
Im assuming this is due to me being behind a corporate proxy. As counter measures I have explicitly configured VSCode, Git, pip, go and google cloud sdk all to use said proxy. On top of that I set the Windows ENV variables for the proxy. sadly without success.
Thanks!
You can configure docker to pass through proxy information into the containers by adding something like the following to your ~/.docker/config.json:
{
"proxies": {
"default": {
"httpProxy": "http://192.168.1.12:3128",
"httpsProxy": "http://192.168.1.12:3128"
}
}
}
Docker will set the HTTP_PROXY/HTTPS_PROXY environment variables within the container which is picked up by many tools.
I was aiming to config the location of spring cloud config server by setting spring.applicaton.name and server.port and eureka.client.serviceUrl.defaultZone in application.properties together with spring.cloud.config.discovery.enabled=true and spring.cloud.config.discovery.service-id=cloud-config in bootstrap.properties, which turned out to be insufficient. The following error messages are shown in log:'
com.netflix.discovery.DiscoveryClient : DiscoveryClient_BOOTSTRAP/192.168.1.5:bootstrap - was unable to refresh its cache! status = Cannot execute request on any known server
No instances found of configserver (cloud-config)
According to the docs, I moved eureka.client.serviceUrl.defaultZone into bootstrap.properties and succeeded.
My question is, if spring.application.name and server.port are essential for a eureka client to register on the eureka server, why they can be unsettled in bootstrap.properties for the config client?
I suspect that the config client will first use eureka.client.serviceUrl.defaultZone alone to connect with the eureka server and fetch service registration informations but not register itself so as to locate the config server and pull something. After that, since the config client is also a eureka client, it uses relative parameters in application.properties to register on eureka server. As some evidence of my suspect, I found the following logs during the startup of the application:
2017-09-07 06:13:09.651 INFO [bootstrap,,,] 74104 --- [ restartedMain] com.netflix.discovery.DiscoveryClient : Getting all instance registry info from the eureka server
2017-09-07 06:13:09.817 INFO [bootstrap,,,] 74104 --- [ restartedMain] com.netflix.discovery.DiscoveryClient : The response status is 200
2017-09-07 06:13:09.821 INFO [bootstrap,,,] 74104 --- [ restartedMain] com.netflix.discovery.DiscoveryClient : Not registering with Eureka server per configuration
2017-09-07 06:13:37.427 INFO [-,,,] 74104 --- [ restartedMain] com.netflix.discovery.DiscoveryClient : Getting all instance registry info from the eureka server
Is it?
Good morning.
I am an intern currently working on a proof of concept requiring me to use zoomdata to visualize data from elasticsearch on ubuntu 16.04 LTS.
I managed to connect both on docker - in short, each process ran in a separate, isolated container and communicated through ports - but the performance wasn't good enough (the visualisation encountered bugs for files > 25 mb).
So I decided to install zoomdata on my computer (trial, .deb version)
I also installed mongodb first.
However, when I run zoomdata, I have two issues, and I believe that solving the second might solve the first:
-the first is that when I create a new elasticsearch connexion, I enter exactly the same parameters as with docker (I've triple checked, they are accurate):
node name: elasticsearch (the name of my node)
client type : HTTP node
adress: 192.168.10.4 and port: 9200
-the second is when I run zoomdata:
During the initialisation (more accurately, the spark one) I have an error message (more details below):
c.z.s.c.r.impl.CategoriesServiceClient : Attempt: 1 to send
categories registration failed. Connect to localhost:3333
[localhost/127.0.0.1] failed: Connection refused
followed by the same message over and over again (the attempt number changes) as the rest of the program executes normally.
I took a look at the logs - computer(bug) and docker(works).
Note: the SAML error doesn't stop the docker version from working, so unless fixing it fixes other problems It's not my priority.
Computer:
2016-06-15 16:04:06.680 ERROR 1 --- [ main]
c.z.core.service.impl.SamlService : Error initializing SAML.
Disabling SAML.
2016-06-15 15:58:12.125 INFO 8149 --- [ main]
com.zoomdata.dao.mongo.KeyValueDao : Inserting into key value
collection com.zoomdata.model.dto.SamlConfig#4f3431a1
2016-06-15 15:58:12.789 INFO 8149 --- [ main]
c.z.core.init.SystemVersionBeanFactory : Server version 2.2.6,
database version 2.2.6, git commit :
0403c951946e5daf03000d83ec45ad85d0ce4a56, built on 06060725
2016-06-15 15:58:17.571 ERROR 8149 --- [actory-thread-1]
c.z.s.c.r.impl.CategoriesServiceClient : Attempt: 1 to send
categories registration failed. Connect to localhost:3333
[localhost/127.0.0.1] failed: Connection refused
2016-06-15 15:58:17.776 ERROR 8149 --- [actory-thread-1]
c.z.s.c.r.impl.CategoriesServiceClient : Attempt: 2 to send
categories registration failed. Connect to localhost:3333
[localhost/127.0.0.1] failed: Connection refused
2016-06-15 15:58:18.537 INFO 8149 --- [ main]
c.z.c.s.impl.SparkContextManager$2 : Running Spark version 1.5.1
Docker:
2016-06-15 16:04:06.680 ERROR 1 --- [ main]
c.z.core.service.impl.SamlService : Error initializing SAML.
Disabling SAML.
2016-06-15 16:04:06.681 INFO 1 --- [ main]
com.zoomdata.dao.mongo.KeyValueDao : Inserting into key value
collection com.zoomdata.model.dto.SamlConfig#43b09564
2016-06-15
16:04:07.209 INFO 1 --- [ main]
c.z.core.init.SystemVersionBeanFactory : Server version 2.2.7,
database version 2.2.7, git commit :
97c9ba3c3662d1646b4e380e7640766674673039, built on 06131356
2016-06-15
16:04:12.117 INFO 1 --- [actory-thread-1]
c.z.s.c.r.impl.CategoriesServiceClient : Registered to handle
categories: [field-refresh, source-refresh]
2016-06-15 16:04:12.427 INFO 1 --- [ main]
c.z.c.s.impl.SparkContextManager$2 : Running Spark version 1.5.1
The server versions are different (2.2.6 for computer, 2.2.7 for docker) - I'll try to update the computer one but I don't have much hope that it will work.
What I tried already:
-use zoomdata as root: zoomdata refused, and internet told me why it was a bad idea to begin with.
-deactivate all firewalls : didn't do anything.
-search on the internet: didn't manage to solve.
I'm all out of ideas, and would be grateful for any assistance.
EDIT : I updated to 2.2.7, but the problem persists.
I'm wondering if there may be a problem with authorisations (since the connexion is refused).
I also tried disabling SSL on my zoomdata server.
EDIT: after a discussion on the logs and .properties files seen here
the issue is the scheduler service not connecting to mongodb, although zoomdata does connect.
I filled the files following the installation guide but to no avail.
From the logs I see that scheduler cannot connect to mongo because socket exception. Found possible solution here:
stackoverflow.com/questions/15419325/mongodb-insert-fails-due-to-socket-exception
Comment out the line in your mongod.conf that binds the IP to 127.0.0.1. Usually, it is set to 127.0.0.1 by default.
For Linux, this config file location should be be /etc/mongod.conf.
Once you comment that out , it will receive connections from all interfaces.
This fixed it for me as i was getting these socket exceptions as well.