I am trying to run Sentiment analysis from Azure Cognitive Services using an official docker image. Azure Cognitive Service for Language resource is up and running in Azure, but the container can't reach the Billing endpoint.
The container is started as described in the documentation (with the correct billing and key):
docker run --rm -it -p 5010:5000 --name sentiment_cmd mcr.microsoft.com/azure-cognitive-services/textanalytics/sentiment Eula=accept Billing=https://RESOURCENAME.cognitiveservices.azure.com/ ApiKey=KEY
but in result I always get
Failed to reach billing endpoint: 'Resource temporarily unavailable'. Trying 9 more times.
fail: Microsoft.CloudAI.Containers.Http.CloudClient[0]
Failed to reach billing endpoint: 'Resource temporarily unavailable'. Trying 9 more times.
I tried changing the default IP subnet choosen by docker engine, but it didn't fix the issue. Any ideas?
As you are telling the Azure Cognitive Services for Language service is up and running. The problem is with the subnet. Need to check with whether billing endpoint is running with the subnet of the applications is running. Check whether the billing is in private or public subnet and also application is. Even though the service is running and if still it is not responding. Check with the network connections. Check with the network traffic also for the same issue. Reset or recheck the key before connecting.
Related
I'm currently having some issues to sign in to a private AKS Cluster with the following commands:
az account set --subscription [subscription_id]
az aks get-credentials --resource-group [resource-group] --name [AKS_cluster_name]
After I typed those two commands it ask me to authenticate through the web with a code that is generated by AZ CLI, and after that, I have the following issue on the terminal:
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code RTEEREDTE to authenticate.
Unable to connect to the server: dial tcp: lookup aksdusw2aks01-0581cf8f.hcp.westus2.azmk8s.io: i/o timeout
What could be the potential issue? How can I successfully login to a private AKS Cluster?
Notes:
I have some other clusters and I'm able to login to them through the terminal without having any type or kind of errors.
You cant use kubectl to access the API Server of a private AKS cluster, thats the design by making it private (no public access). You will need to use az aks command invoke to invoke commands through the Azure API:
az aks command invoke -n <CLUSTER_NAME> -g <CLUSTER_RG> -c "kubectl get pods -A"
Timeouts typically mean something somewhere is dropping packets and there is no response. This might be the security policies and/or traffic rules inside your Azure cloud that are configured for your AKS cluster. You can double check this is coherent with the one where you say your cluster is accessible.
In order to interact with the private cluster you'll need to run your command lines from endpoint that has access to the VNET that the AKS cluster is in. So you'll need a VM in that VNET, or a VNET that is peered, VPN in etc.
The point of the private cluster is to prevent access from external sources, only connected networks are allowed.
You can also, as mentioned by Wlez, use command invoke, but this is probably suited to occasional use, rather than responsive, frequent access.
There is an intermittent issue while downloading docker images in a Linux VM. As per docker service journalctl logs I can see below error-
level=error msg="Handler for POST /images/create returned error: Get
"https://<containerregistry>": dial tcp: lookup
https://<containerregistry>: device or resource busy".
Initialy I thought it could be intermittent connectivity issue with container registry (Azure Container Registry) but that is not the case since even with retries at different time periods I got the same error.
I have checked the docker daemon.json config and don't see any issue with that. I also verified DNS servers in systemd-resolve and can see the expected IPs as required. Interestingly, another VM with same configs works fine.
I am using .Net Client for Docker Remote API (https://github.com/dotnet/Docker.DotNet) to trigger docker image updates. The client is hosted in a Linux VM which is triggered by via socket as an RPC call. It reaches the client and executes the API ImageOperation.CreateImageAsync.
Can someone help with this? Please let me know if I can add more details.
• Regarding the error that you are encountering, I would suggest you to please check the azure container registry health first by executing the below command: -
az acr check-health --name registryname --vnet virtualnetworkname
Then, check the internet upload and download speed through ‘AzureSpeed’ tool to the container registry which hosts the images layers. Also, it may be that the image size may not be supported for the registry service tier due to which it is not available.
• Ensure that both your ‘docker client’ and ‘docker daemon’ are configured for proxy behavior behind HTTPS proxy. If you have changed or updated any proxy settings, kindly ensure to restart the daemon service.
• Check the ‘Registry resource logs in the ContainerRegistryLoginEvents table’ for further diagnosis of an attempted connection. Also, check whether the registry is accessible over the internet and allow access to the public registry endpoints from all networks. If the container registry is configured for selected virtual network with a service endpoint, then disabling public network access also disables access over the service endpoint.
• If a private endpoint is configured for the container registry, confirm that the DNS resolves the registry's public FQDN such as myregistry.azurecr.io to the registry's private IP address. Use a network utility such as ‘dig’ or ‘nslookup’ for DNS lookup. Ensure that DNS records are configured for the registry FQDN and for each of the data endpoint FQDNs as per the below documentation link: -
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-private-link#dns-configuration-options
• If a service endpoint to the registry is configured, confirm that a network rule is added to the registry that allows access from that network subnet. Also, ensure that the resource provider for Azure Container Registry is registered.
For more details regarding the further steps to take to perform regarding the error that you have encountered, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-troubleshoot-access#configure-service-access
I have a Linux Virtual Machine (Debian 9) deployed in Azure with Service Endpoints for Sql enabled and properly added -if I navigate the portal towards the VNet and enter the Service Endpoints tab, I can clearly see the Sql Service Endpoint listed. Just FYI, the reason for the Service Endpoint is that the VM has a dynamic IP, so I can't just whitelist it in the DB resource's configuration.
On the other hand, I have an 'Azure Database for MySQL server' deployed in the same resource group, same location and whatnot, but I can't seem to connect to it.
The steps I take when I try to connect are as follow:
I connect to the VM through SSH.
In my VM I have mysql-server installed
I write mysql --host <fully qualified server name> --user <server admin login name>#<server name> -p
I get the following error: "ERROR 9002 (28000): Server is not ready for incoming connections."
I've been reading the documentation and searching in forums for a reason why this might be happening, but I simply cannot seem to make it work. I have tried changing the status of the "Allow access to Azure services" option in the Connection security tab of the DB resource, but it doesn't seem to matter.
Could anyone have any idea of how I might go about solving this??
You said you enabled the SQL endpoint on the virtual network, but did you add a VNET rule to the instance (Attach an existing VNET)? You can find this in Azure Database for MySQL server -> Connection Security -> VNET Rules -> Attach existing VNET.
If you can't see your VNET listed then there is a mismatch between the regions of your SQL server and your VNET: They must be deployed to the same one. Additionally check that you have a General Purpose or Memory Optimized server, this feature is not available in Basic tier.
If all of this is in place, try enabling Diagnostics on the SQL Server, try logging in again a few times, then view the log file and post anything strange.
So I am fairly new to Kubernetes. I am a Windows user (sorry) and have installed Minikube. I am trying to learn Kubenetes using MiniKube. I have created very simple REST API that should work with port 5000 exposed where there is a simple route /Hello/{somestring}
I have created a POD/Deployment and Service for this successfully in MiniKube like this
minikube.exe start --kubernetes-version="v1.9.0" --vm-driver="hyperv" --memory=1024 --hyperv-virtual-switch="Minikube Switch" --v=7 --alsologtostderr
kubectl run simple-sswebapi-pod-v1 --replicas=1 --labels="run=sswebapi-pod-v1" --image=sachabarber/sswebapp:v1 --port=5000
kubectl expose deployment simple-sswebapi-pod-v1 --type=NodePort --name=simple-sswebapi-service
kubectl get services simple-sswebapi-service
Which I can then grab the url from and paste into my browser like so
minikube service simple-sswebapi-service --url
Which gives me this URL
http://192.168.0.29:32246
Which I then try in the browser on my host, all is good my REST API is running as expected
But from what I have read, I believe I should be able to ALSO use a DNS name for the service rather than this url returned above.
In fact I am not sure what this IP address returned as part of the --url command is trying to tell me above. It is not one of the ones listed for the service endpoints for is it for the POD from what I can tell from the Dashboard.
This is the service
This is the POD
Shouldn't there be a DNS name available for the service that I should be able to use instead of this fairly hacky way of grabbing the url from the service I just created. Someone please let me know what this --url even represents. I am lost here
I have checked that the DNS add on is enabled in MiniKube it is, see kube-dns in list below
As I say this is also what I see for the service inside of the MiniKube Dashboard
This confused me even more as I cant seem to tie any of that back to the ONLY IP address that seems to actually work for me, which is the one I grabbed using this line from the service
.\minikube.exe service simple-sswebapi-service --url
This Ip Address is not shown in the dashboard at all.
I thought the service should be available at DNS name something like:
simple-sswebapi-service.default.svc.cluster.local
Which is the
The name of the service
The namespace
svc to tell its a service
Just for completeness this is me describing the service in command line
What am I missing?
Is my mental mode wrong. I should be able to see this service using a DNS in the host too? Or is the DNS name ONLY available inside the PODS?
kube-dns is internal DNS. You can only use the DNS name for a service from inside the cluster.
Since your service type is Nodeport, you can connect to the service using the IP of the machine (minikube) on that port.
I was following the process mention on the azure site to create a docker machine in azure.
The docker was able to create the necessary components in Azure but comes back with the message of
No connection could be made because the target machine actively refused it.
Building the docker image or simply trying to query it with docker images returns this message.
I suspect that the IP Address assigned is not made public although it is configured in Azure. .
This is probably not docker related but to the Azure configuration. How does one ensure the IPAddress here is accessible and connectable externally?