SpringBoot @RestController недоступен из внешнего контейнера докеров

Question

tl; dr One RestController отвечает правильно, а другой нет, если он запускается внутри контейнера Docker.

Служба имеет два API, alive

@CrossOrigin(origins = "*", maxAge = 3600) 
@RestController 
public class AliveController { 
    @RequestMapping(value = "/alive", method = RequestMethod.GET) 
    public ResponseEntity<?> alive() { 
     return new ResponseEntity<>(HttpStatus.OK); 
    } 
} 

и callcount.

@CrossOrigin 
@RestController 
public class CallController { 

    private static int callCount = 0; 

    @RequestMapping(value = "/callcount", method = RequestMethod.GET) 
    public ResponseEntity<?> callCount() { 
     return new ResponseEntity<>(++callCount, HttpStatus.OK); 
    } 
} 

Они оба проходят через докер-композицию.

version: '2' 

services: 
    service: 
    image: my/service 
    ports: 
     - "4000:4000" 

docker-machine ip возвращается 192.168.99.100.

alive возвращает пустой ответ 200. Как и ожидалось.

$ curl -i http://192.168.99.100:4000/alive 
HTTP/1.1 200 
Content-Length: 0 
Date: Mon, 22 Aug 2016 17:33:58 GMT 

callcount должен возвращать ответ 200 и число, которое увеличивает каждый раз, когда API называется. К сожалению, это не так.

$ curl -i http://192.168.99.100:4000/callcount 
HTTP/1.1 404 
Content-Type: application/hal+json;charset=UTF-8 
Transfer-Encoding: chunked 
Date: Mon, 22 Aug 2016 17:37:26 GMT 

{"timestamp":1471887446871,"status":404,"error":"Not Found","message":"No message available","path":"/callcount"} 

Запуск службы локально обеспечивает ожидаемый результат.

$ curl -i http://localhost:4000/callcount 
HTTP/1.1 200 
Content-Type: application/json;charset=UTF-8 
Transfer-Encoding: chunked 
Date: Mon, 22 Aug 2016 17:43:40 GMT 

1 

The Maven-Spotify плагин используется для создания изображения из следующего Dockerfile.

FROM java:8 

EXPOSE 4000 

VOLUME /tmp 
ADD service*.jar app.jar 

# http://stackoverflow.com/a/33882286/1309035 
# Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly. 
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"] 

Я использую последние Docker и Докер-Compose версии (они были загружены 22 августа 2016 г.).

Решено! См. Раздел ниже. Будет завершен вопрос, когда окончательный ответ будет найден. - Вопрос: Почему callcount недоступен снаружи контейнера Docker?

Дальнейшие попытки:

• @CrossOrigin(origins = "*", maxAge = 3600) - тот же результат
• глобальной конфигурации CORS от the spring docs.
• Объединение двух методов в AliveController.
• Удаленный каждый контейнер и изображение и докер построены снова с нуля.

Udates:

callcount API не зарегистрирован весной. Я добавил еще один API test, чтобы проверить это, которое также недоступно через curl. alive все еще отлично работает и появляется в журналах.

bash-3.2$ docker logs asmstack_service_1 | grep callcount 
bash-3.2$ docker logs asmstack_service_1 | grep test 
bash-3.2$ docker logs asmstack_service_1 | grep alive 
2016-08-23 08:42:06.530 INFO 1 --- [   main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/alive],methods=[GET]}" onto public org.springframework.http.ResponseEntity<?> de.bahr.asmstack.AliveController.alive() 

---

Я использую JDK 1.8 локально (java.vm.vendor = Корпорация Oracle).

$ java -version 
java version "1.8.0_74" 
Java(TM) SE Runtime Environment (build 1.8.0_74-b02) 
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) 

Различия между методами запуска

callcount правильно регистрируется при запуске приложения из IntelliJ и mvn spring-boot:run. Он не получает зарегистрированный при запуске с

java -Djava.security.egd=file:/dev/./urandom -jar my-service.jar или

java -jar my-service.jar. Это должно быть причиной того, что он недоступен из контейнера Docker.

Любая идея, почему это так? Он работал так в другом проекте с конца 2015 года

Answer 1

я был в состоянии решить эту проблему с помощью от @ daniel.eichten и @ShawnClark, но я не понимаю, почему это терпит неудачу/работ. T

Это была не проблема Докера, а весна.

Как видно here (вопрос может быть не связан), я изменил весна-приложение из

@SpringBootApplication 
public class Application { 

    public static void main(String[] args) { 
     SpringApplication.run(Application.class, args); 
    } 
} 

в

@EnableAutoConfiguration 
@EnableWebMvc 
@Configuration 
@ComponentScan 
public class Application { 

    public static void main(String[] args) { 
     SpringApplication.run(Application.class, args); 
    } 
} 

Теперь все интерфейсы будут доступны, как ожидается, также при работе внутри Докер контейнер.