Unfortunately I face problems with deployment to Marathon.
I do curl -X PUT -H 'Content-Type: application/json' -i http://marathon_url/v2/apps/lookout -d#lookout.json
And receive response:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Connection: close
Server: Jetty(8.y.z-SNAPSHOT)
That's it. No deploymentId returned in response.
Sometimes it needs to do around 10 curl to get an app deployed.
Sometimes I receive deploymentId, but anyway nothing changed in Marathon UI.
Marathon version: 0.9.2
Does anybody have the same problem?
PUT is for changing the config of an already deployed app. Use POST to deploy an app.
Related
I am attempting to create GA4 analytics events by POST-ing to the URL with the same details as a web app:
curl -X POST "https://www.google-analytics.com/collect?v=2&tid=<MY_TID>&cid=<MY_CID>&t=event&en=someNonsense&ep.aParameter=value&z=1234567890" -H "Content-Type: text/plain;charset=UTF-8" -H "sec-fetch-mode: no-cors" -H "sec-fetch-site: cross-site" -H "sec-fetch-dest: empty" -H "pragma: no-cache" -H "cache-control: no-cache" -H "origin: http://localhost:5000" -H "content-length: 0" -H "accept-language: en-US,en;q=0.9" -H "accept-encoding: gzip, deflate, br" -H "user-agent: dummy"
All of these events show up perfectly in the realtime view, and if I add &_dbg=1 to the URL, these events and all their parameters show up consistently and reliably in the DebugView too.
I waited 48 hours and the events didn't show up. I did the following to try to bring things to life:
added all the event parameters as custom metrics
disabled the internal traffic filter which is active by default
dug through the settings and agreed to the "Data Processing Terms"
I then waited a further 48 hours and nothing has changed. Things seem to work just fine if I do them through a browser with firebase-analytics.js.
Does anyone have any idea what I've missed/broken?
Is Google doing some post processing on events to make sure they're coming from a real web page? I can mimic the HTTPS requests of the browser and the events still wont get recorded.
I can see my events showing up in realtime on my GA4 account. Perhaps you need to debug your events using the https://ga-dev-tools.web.app/ga4/event-builder/
I've managed to get things working.
It turns out GA4 will not log events unless they are part of a session. If I send a session_start event with ga_session_number and ga_session_id properties, any subsequent events will be properly recorded for the duration of the session.
I have succesfully deployed a stream using spring dataflow in eks, but I need to debug an application of the stream.
I have set up spring.cloud.deployer.kubernetes.environment-variables: JAVA_TOOL_OPTIONS='-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000' in the application I want to debug, and the application starts an it is listening on that port.
Is there any property to tell kubernetes to map this port and make it accessible?
Thank you.
Try this:
And then try a kubectl port-forward
service/YOUR_SERVICE_NAME Host port:Service port
The documentation is really complete btw, there's a lot of information here:
https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/
Thanks #bguess for point me into the rigth direcction.
Finally this is what I have done:
When we are going to deploy With web interface we click edit button of the application we want to debug:
add JAVA_TOOL_OPTIONS='-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000' into environment-variables.
In my case I have kubernetes on aws and is deployed in private mode and the only way I have found in this moment is to create a LoadBalancer for the application. I know it is insecure but itś enough for my needs.
Finally as #bguess pointed we have to add our debug port to serverPorts, this property isn't in the list when we psuh edit button in the application so we have to write it:
So this is the way to configure with the web interface.
If we want to use a terminal in linux or similar we can do this steps:
definition="app-source | app-process | app-sink"
curl "$scdf_url/streams/definitions" --write-out '%{http_code}' --silent --output /dev/null -X POST -d "name=poc-stream&definition=$definition&deploy=false"
Where definition is our stream definition and scdf_url is the spring cloud dataflow server url. After the curl call we will have our stream created but undeployed, To deploy with the debug configuration:
properties="$(cat << EOF
{
"deployer.app-source.kubernetes.environment-variables":
"JAVA_TOOL_OPTIONS=’-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000’",
"deployer.app-source.kubernetes.servicePorts":"8000",
"deployer.app-source.kubernetes.create-load-balancer":"true"
}
EOF
)"
curl "$scdf_url/streams/deployments/poc-stream" --write-out '%{http_code}' --silent --output /dev/null -X POST -H "Content-Type: application/json" -d "$properties"
And that's the way I have configured it.
Additionally you will have to increase inactivity time of the LoadBalancer because his value is 60s and after that time it will disconnects you.
I want to use curl http://127.0.0.1:8033/api/v1 to access https://http2.pro/api/v1 with HTTP/2
This API url will return whether the client using http2.
I have tried: (I'm using latest version 5.0.1)
./mitmdump -p 8033 --http2 --set http2_priority=true --mode reverse:https://http2.pro:443
However curl 127.0.0.1:8033/api/v1 still gives:
{"http2":0,"protocol":"HTTP\/1.1","push":0,"user_agent":"curl\/7.69.1-DEV"}
In contrast, curl https://http2.pro/api/v1 --http2 gives: (this is what I expected)
{"http2":1,"protocol":"HTTP\/2.0","push":0,"user_agent":"curl\/7.69.1-DEV"}
mitmproxy currently does not support converting between HTTP/1 and HTTP/2. For HTTP/2 to happen, both endpoints need to speak it. It is on our todo list and will hopefully be possible soon (https://github.com/mitmproxy/mitmproxy/issues/1775).
I am trying get current component version of component that is deployed to an environment in UCD via REST API/Curl command . Below is sample code which returns all versions of that component which is available in UCD. It does not give me latest version of that component deployed to an environment. Any help / suggestion?
curl -k -u userName:passw0rd \
-H "Accept: application/json" \
"https://myserver.example.com:8443/rest/deploy/environment/{environmentID}/versions/{componentID}"
uDeploy has a bunch of api endpoints that are undocumented. I could not figure out how to do this from their docs but inspecting the uDeploy web interface many times can help you find the endpoint to hit.
https://{your-udeploy-url}/rest/deploy/environment/{your-environment-id}/latestDesiredInventory/true?rowsPerPage=10000&pageNumber=1&orderField=name&sortType=desc
This will return json that you can parse to get the versions deployed in an environment.
I believe that Mongrel is a single thread web server. So I suppose it will be blocked if user is uploading a huge file.
However, I did a test today, it seems not true.
I uploaded a file with curl like this:
time curl -k -F myfile=#/tmp/CGI.19974.3 -H 'LOGIN_NAME:admin' -H 'PASSWORD:pass' http://10.32.119.155:3000 -v
Here is the result:
real 6m38.756s
user 0m0.232s
sys 0m9.561s
You can see that this uploading cost 6 minutes. But during this period, the mongrel works well, it can handle the request correctly.
So, Can I say that there is another thread to handle the uploading?