I have a container, it's running on port 8008, and it's accessible using the URL example.com. Inside the container, there's a server that provides an API and an APP. In some part of the APP, I'm making a request to the API, but when I do that, start a loop and the request never finish, and I need to restart the container.
For example, I make this request: https://example.com/server_version to get the version of the server, this request freeze the container.
Anyone knows how to fix this?
Related
I want to setup a local IMAP server within my home network for archiving emails. The server does not need to be accessable via the internet. Therefore I can pass on a secured access via SSL (If this makes it easier). I want to integrate the server in my current docker setup. So the server has to run within a docker container.
I already tried the following containers:
https://hub.docker.com/r/blackflysolutions/dovecot
https://hub.docker.com/r/dovecot/dovecot
https://hub.docker.com/r/mailu/dovecot
https://hub.docker.com/r/mailcow/dovecot
https://hub.docker.com/r/eilandert/dovecot
But i could not get any of them to run. At the same time none of them have a forum or anything where I can put a question. Two of them (mailu/dovecot and mailcow/dovecot) are part of a bigger mailserver package. Which I do not need, I only want a IMAP server to put some email locally. But I tried them anyway.
Does anyone know how to get any of those to run? Or suggest me another stable docker container solution.
I run my application that grabs data from an external API in a Docker container (alpine). I use Docker Desktop 4.1.1 on macOS Monterey 12.5.
Every now and then my app needs to refresh its auth token. Everything works well.
But sometimes I get timeouts on request to refresh the token (lets say it's auth.example.com).
I think auth.example.com might be rate limiting those calls but:
It works no problem when I request same thing from my host (outside Docker) at the same time when it timing out in a container
After I restart Docker it works right away from inside a container
Issue disappears after some (random?) time. Sometimes it's 30 minutes, sometimes it's hours
I tested it from different containers made from different, clean (Debian, alpine, Ubuntu) images - calls to auth.example.com are timing out from all of them
I tried telneting telnet auth.example.com 443 and it timeouts inside Docker and works well from my host
At the same time telnet google.com 443 works well from inside my containers
I tried running hundreds of those requests from my host in a loop to see if it gets blocked but it doesn't (and my app inside a container requests that only once an hour maybe)
Seems like Docker is adding something in the request that allows auth.example.com to filter those requests maybe?
But I tried sending requests from inside my container and from my host to RequestBin and all headers look the same.
I tried using mitmproxy and Proxyman to watch the requests but auth.example.com uses SSL pinning and I was not able to configure it properly.
I don't know how to debug that further. Any ideas?
(I am using Spotify's API, with Spotipy library, and calls that time out are made to accounts.spotify.com).
I have a java application as JAR. This JAR application runs fine from my machine, meaning it can send and receive HTTP Requests to and from an API Endpoint (let's call this endpoint example.com/api/).
And then i built a docker image of this JAR Application, and tried to run the image as container from my docker desktop. But then i got this error.
the error i got
it seems like my application cant reach the url from inside the docker container. I tried to set the proxy in Settings -> Resources -> Proxies -> Manual proxies configuraton, and put my company proxy since i'm inside my company network. But still it doesn't work.
I tried to google this problem but almost nothing shows up (anything that shows up have little correlation with my problem). Anyone knows what seems to be the problem? What should I do?
First check if your container is able to communicate with the endpoint. Ping or curl it from the container shell. If you use proxy, set environment variables in container:
export http_proxy=http://server-ip:port
export https_proxy=https://server-ip:port
I'm sure this is possible somehow, but never really had a need to do so previously. I have a bunch of Docker containers that run on an UBUNTU host. One of the containers is an NGINX server that serves as a webserver and reverse proxy. What I would like to do is setup some sort of 'switch' or mechanism on the host or preferably another device that does something like described below. The server does have production and development versions of the web applications, so I really just want to set a header if it is running but in maintenance.
Set up something on the host other device that indicates or detects the state of the NGINX server.
a. Running normally.
b. Running but undergoing maintenance (would have to be manually set into that mode)
c. Not running.
Depending upon the state in 1 it would do the following:
a. Just pass the request through to the server.
b. Pass through the request, but possibly set a header or something to indicate it is in maintenance mode.
c. Redirect the request to an external URL, basically the public facing page for the business.
Not really sure how to approach that since it seems that I would need an HTTP listener on the host, or possibly on a router or firewall or other device (we have a Fortigate and a Watchguard). That would check the HTTP request, and then take the appropriate action based upon what "mode" we are in. The UBUNTU host is pretty much bare bones, i.e. without Apache or another web server because everything is pretty much in the Docker package.
If I were to set that up on the Debian host, seems like we could just have an environment variable that defaults to PROD and then just set it to DEV when we are working on the code, and then set it back to PROD when we are done, and then the process would.
ping the DOCKER NGINX instance to see if it is running (i.e. status code).
if it is running and PROD, just forward on.
if it is running and DEV, set a header to indicate so and forward on.
if it is not running, redirect externally.
If the server is completely down though, that would fail.
Any ideas as to how to actually do that ? Ideally the 'processor' would not reside on the UBUNTU server at all and would always be running.
(This is a follow up to rails app fast on server, but slow when accessed from another machine.)
I have a Rails web app that's incredibly slow when I access via its hostname, but runs at normal speeds when I access via its IP address (or via localhost, if I access it on the same server machine it's running on). This makes me think the problem is with the DNS. (Also, all these machines are running on the same corporate intranet.)
However, when I ping the hostname from a terminal, the ping seems to run fine. Does the fact that pinging works suggest that the problem is not with the DNS? (I don't really know much about DNS or servers and networking, so I'm kind of floundering around a bit here.)
Update to add: I also ran a simple "Hello world" Sinatra app, and this also runs super slowly when accessed via hostname (but not when accessed via IP address).
Fast ping from your terminal suggests that DNS between you and DNS server was fine and that network between you and server is fine.
This still does not help with the DNS on your server. Do you have any network operations that your server performs? If so, you need to make sure the network is reachable.
I suggest you get a simple "hello world" Rails application deployed there and see if it is Rails issue related (server wide) or your application related (very easy to do).
The other suggestion is to profile your Rails app and see which operation is taking the time to complete.
Your ping command is probably using cached DNS instead of hitting the server every time. Google for "flushdns" to find the right syntax to purge your cache for your particular operating system, then try it. You'll need to do this every time if you want to use ping to see about DNS response.