I'm using AWS ECS to practice and I met this issue when launching my task, it failed with the reason:
CannotPullContainerError: inspect image has been retried 5 time(s): failed to resolve ref "docker.io/vaultwarden/server:latest": failed to do request: Head https://registry-1.docker.io/v2/vaultwarden/server/manifests/latest: dial tcp 3.226.210.61:443: ...
In task definition I'm using the image url from docker hub which i believe is an official image(docker.io/vaultwarden/server:latest
)
After doing some research, I checked my VPC, subnet(can access public internet), IAM, and tried whether enable auto assign public IP or disable it when I created the service, also I compared my task definition with my colleague and can't tell the difference, but his working fine.
After that, I tried to delete everything, cluster, service, task definition, etc and even switched my aws account to anther zone(from California to Oregon) and tried from scratch.
Finally I still get this same error, is my account been blocked for some reasons or anyone can provide some helps to me? I really appreciate that!
Related
I have an application running in Openshift 4.6.
The pod is running, I can exec into it and check this, I can port-forward to it and access it.
when trying to access the application, I get the error message:
Application is not available The application is currently not serving
requests at this endpoint. It may not have been started or is still
starting.
Possible reasons you are seeing this page:
The host doesn't exist. Make sure the hostname was typed correctly and
that a route matching this hostname exists.
The host exists, but doesn't have a matching path. Check if the URL
path was typed correctly and that the route was created using the
desired path.
Route and path matches, but all pods are down. Make sure that the
resources exposed by this route (pods, services, deployment configs,
etc) have at least one pod running.
There could be multiple reasons for this. You don't really provide enough debugging details to get to the next steps. But I generally find it helps to work backwards through the request.
Can you access the pod via port-forward? You say you've already tested this, but I include it for completeness. But I also mention it to make sure that you are verifying that you are serving the protocol you expect. If you have HTTPS passthrough on the route, but you are serving HTTP from your pod, there will obviously be a problem.
Can you access the pod providing your service from outside the pod (but within the cluster)? e.g. create a debug pod and see if you can connect to your service with curl some other client. If this doesn't work, you may not be exposing the ports of your pod correctly. Check the pod definitions.
Can you access the service from outside the pod (but within the cluster)? e.g. from your debug pod, use the service directly. If this doesn't work, you may have the selector on your service wrong. Or some other problem with your service. Check the service definition.
Can you access the route from inside the cluster? e.g. from your debug pod, try to use the full route URL. If this doesn't work, you've narrowed it down to the route definition. Again, HTTPS vs HTTP can sometimes be a mistake here such as having HTTPS passthrough when your service doesn't support HTTPS. Check the route definition.
Finally, try accessing the route eternally. Which is sounds like you have already tried. But if you've narrowed it down such that your route works internally you've determined that the problem is something in the external network. It doesn't sound like this is your problem, but it's something to keep in mind.
I'm new on AWS but I read a lot of documentation to create, launch and image instances. Now I have a client that use AWS and have 2 instances EC2 runing commercial web sites (using Nginx and MySQL in Amazon RDS and Wordpress).
I need to create clones of this websites to have a Q.A. ambient. I try creating images from these instances and launching new instances with this, but this don't work. When I Try to visit the website clone using the IP of the instance, that shows a 504 error. (The idea is to have two instances ready to use with the same website. One for visitors use and another to do testes, updates, changes or to use when the another instance crash)
The on-air website domain is ibser.org, and the new instance domain (runing now) is link to instance
Somebody may give me info that what can I do?
#Wilmar Sometimes it do happen as you have created the image successfully but due to manual setup you have to start the services inside the Instance manually.
As per the link provided, its showing 504 Gateway time out, so please check with the Security group of your newly created Instance and sometimes A corrupt WordPress database may also trigger a 504 gateway timeout error. This means may be your mysql service is not running.
So my suggestion is SHH into your New instances and check with all the required services which all need to be in running state and do check with the database.
I have a basic stack of containers on their own user-defined network with a subnet of 172.21.0.0/16. My MySQL container's address is 172.21.0.2 and the PHP/Apache container's address is 172.21.0.3.
Until this point I had to permit MySQL to allow incoming connections via PHP from 172.21.0.3, which made perfect sense. Now, it seems as though the connections are coming from 172.21.0.1, the gateway, and this doesn't make much sense to me. My (basic to intermediate) understanding suggests that the gateway should only be used when traffic is destined for an address outside of its local network - but obviously in this case MySQL and PHP/Apache are on the same network.
Two of our environments have started acting like this, and while it's a simple fix to permit connections from the gateway address, I'm hesitant to proceed without an understanding as to what has happened and why. This also seems to add extra delay to database queries within the application.
Logging in to an affected environment via phpMyAdmin displays "User: root#172.21.0.1" in the "Database Server" information pane. An unaffected environment displays "root#phpmyadmin_1.test_default" (user#[container].[network]).
Both environments are using the exact same images, and the same version of Docker - 18.06.1-ce. Other than a version upgrade of Docker, nothing else has changed with regards to the docker-compose.yml I was using.
Why has my environment started acting like this? Should I prefer the connection coming in from the actual source, and not via the gateway? How can I return to that way of operation?
Thank you for any guidance or knowledge.
For anyone else that experiences a similar rut, I'm of the mind that this was caused by an upgrade of Docker from 18.03.1-ce to 18.06.1-ce via Docker's own repository. Performing a server reboot after this operation has (for now) restored sense to the networking of the stack.
The connection to my MySQL container is now correctly coming from the PHP/Apache container and not from the gateway address of the bridge network. The lag this introduced is gone, and I'm able to remove the privilege associated with the gateway address.
My google cloud instance (10.128.0.3) lost network connectivity somewhere just after 0400 this AM. I am running Centos 6.10) The network interfaces are up and have IP addresses. Unable to ping default gateway (10.128.0.1). Firewall rules (google and local) have not been changed/modified. This instance has been online for several years with no recent changes made. Any suggestions would be helpful and appreciated.
This is a known issue when updating to kernel 2.6.32-754 that is affecting both Red Hat, and CentOS images, and seems related to this DHCP update. The Compute Engine team are already aware of this issue.
Meanwhile, and in addition to the great suggestions above, you may also use a startup script ( add the default gateway IP address) to fix this issue, and then restart your instance. Todo so without access to the instance simply add a metadata for the instance with the name startup-script and the content of the below script (make sure to update the gateway to your, it can be found in the VPC Page)
#!/bin/bash
route add default gw [default_gateway_ip] eth0
For further information/updates about this issue, you may check this issue tracker link. https://issuetracker.google.com/issues/111154121
Our team is trying to troubleshoot an issue we have been encountering with service accounts. The service account we are using is able to create a disk and IP address, however an error is thrown when an instance request is created. All resources can be listed (ie. networks, snapshots, etc.). I have attached a small console snippet below.
The service account is successfully authenticated with JSON key given to me. I have tried altering permissions of the service account and created a new key.
Any assistance is greatly appreciated.
Created [https://www.googleapis.com/compute/v1/projects/<PROJECT>/zones/asia-east1-c/disks/dev-josh-ui-test-08].
Created [https://www.googleapis.com/compute/v1/projects/<PROJECT>/regions/asia-east1/addresses/dev-josh-ui-test-08-ip].
ERROR: (gcloud.compute.instances.create) Some requests did not succeed:
- The resource '<ID>-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found.
I was able to get the exact error provided:
The resource '-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found.
by deleting my default compute service account and attempting to create an instance through the Cloud Shell, so I assume this is the issue.
If the default compute service account was somehow deleted, if has been less than 30 days, you can restore it using: gcloud beta iam service-accounts undelete [ACCOUNT_ID]
https://cloud.google.com/iam/docs/creating-managing-service-accounts#undeleting
After this, you will have to go into https://console.cloud.google.com/apis/dashboard and disable and re-enable the compute engine API. This will take a few moments, but after the GCE API is re-enabled you should be able to create VMs through the Cloud Shell again and I was able to reproduce this.
On https://console.cloud.google.com/apis/dashboard disable the "google compute engine API" and after enable it again.
The enabling also creates some additional setup that is needed to use the API. Those resources could have been deleted by accident beforehand.
You might need to have some patience and wait a minute or two between disabling and enabling.