2017-08-15 30 views
6

Próbowałem wdrożyć kod w środowisku ElasticBeanstalk. Za każdym razem próbuję wdrożyć tę gałąź w środowisku EB zabija wszystkie instancje, ELB, RDS itp. I próbuje odbudować, ale się nie powiedzie. Pozostawia to środowisko w złym stanie, ponieważ usuwa RDS, ale nie usuwa grup bezpieczeństwa ani ENI. Kiedy próbuję ręcznie usunąć grupy zabezpieczeń, nie można powiedzieć, że istnieją zależne obiekty.Nie można usunąć ENI - RDS już usunięty

Prześledziłem go z powrotem do interfejsu sieciowego, ale kiedy próbuję go odłączyć (nawet wymuszam odłączenie), pojawia się błąd, że nie mam pozwolenia. Ten ENI powinien zostać usunięty wraz z instancją RDS, ale tak nie było. Teraz nie mogę całkowicie pozbyć się środowiska i nie mogę go odbudować.

Nie jestem pewien, dlaczego ta aplikacja spowodowałaby, że środowisko podjęło próbę ponownego utworzenia wszystkiego po każdym wdrożeniu, gdy instancje EC2 zniknęły, a następnie po załadowaniu kopii zapasowej są dodawane do ELB, ale ELB nie może wykonać kontrole zdrowotne, dzięki czemu są stale wyłączane z eksploatacji, a środowisko znajduje się w stanie martwym. Byłoby miło, gdybym mógł jakoś zobaczyć dzienniki, co powoduje awarie środowisk z tą aplikacją.

Mając ElasticBeanstalk usunąć wszystkie wystąpienia, w tym RDS, jest nie do zaakceptowania dla wdrożenia, ponieważ musimy ciągle ponownie je wysyłać, nie mówiąc już o tym, że kiedykolwiek zostałyby wdrożone do produkcji, to wyczyściłoby wszystkie dane produkcyjne i nie możemy tego zrobić.

Czy istnieje sposób sprawdzenia, co się dzieje podczas wdrażania i dlaczego tak się dzieje?

+0

EB nie powinien być środowiskami kończącymi podczas wdrażania. Czy widzisz coś niezwykłego na karcie Zdarzenia w konsoli EB? Być może reguła automatycznego skalowania wyzwala i kończy instancję? – Brian

+0

To jest dziennik, możesz zobaczyć wszystko, co dzieje się podczas wdrożenia, aby środowisko zawiodło, ponieważ nowo utworzona instancja ec2 jest postrzegana przez ELB jako OutOfService z jakiegoś dziwnego powodu. Dzieje się tak przy każdym wdrożeniu, nawet gdy odbudowuję środowisko od zera. https://paste.laravel.io/LKLzq Obecnie mam środowisko w zablokowanym stanie, ponieważ próbowałem ręcznie zakończyć i nie byłoby. Nie mogę ręcznie usunąć ENI, ponieważ jest napisane, że nie mam uprawnień, ponieważ proces zakończenia już usunął wystąpienie RDS –

+0

To jest dziennik, od kiedy próbowałem odbudować środowisko po tym, jak wdrożenie się nie powiodło i zainicjowano nowe instancje, ale nie można tego zrobić komunikować się z ELB https://paste.laravel.io/KLoRw Na koniec nie mogę usunąć grup bezpieczeństwa z powodu ENI i nie mogę odłączyć ENI z powodu usunięcia RDS. –

Odpowiedz

0

Elastic Beanstalk wykorzystuje CloudFormation za kulisami. Będziesz mógł usunąć całe środowisko, identyfikując odpowiednie stosy (poprzedzone prefiksem awseb-e-j5zfptidfe-stack według twoich logów) i usuwając je - lub przynajmniej usuwając je z ENI.

Konieczne będzie również usunięcie środowiska z poziomu ElasticBeanstalk. Spowoduje to zresetowanie wszystkiego. Jeśli istnieją stosy zależne - tak jak w grupach bezpieczeństwa. Najlepszym rozwiązaniem jest odczytanie wiadomości w celu określenia zależności i wyczyszczenia ich w pierwszej kolejności.

Dobrą praktyką jest niewłączanie systemu RDS do stosu elastycznych bloków bean, jeśli wiesz, że chcesz zachować w nim dane. Utwórz to osobno i po prostu podaj szczegóły połączenia do swojego stosu. AWS zapewnia detailed instructions. Krótkie podsumowanie byłoby:

  1. Utwórz grupę zabezpieczeń dla bazy danych
  2. Utwórz bazę danych RDS z grupy zabezpieczeń
  3. Dodać parametrach, połączenia z bazą danych jako zmienne środowiskowe do stosu EB
  4. Dodać Grupa bezpieczeństwa EC2 do grupy bezpieczeństwa bazy danych jako dozwolone źródło ruchu do bazy danych.

Wreszcie. Musisz określić, dlaczego instancje są kończone w twoim stosie. Wygląda na to, że nie stają się "zdrowe". Wyłącz Ignore health check, która jest opcją dla wdrożeń Elastic Beanstalk.

Powinno to spowodować powstanie środowiska z instancjami EC2 oznaczonymi jako "niezdrowe". Następnie możesz użyć dowolnych narzędzi, aby zdiagnozować, dlaczego instancje EC2 nie odpowiadają poprawnie na health checks i rozwiązać problem.

Może być wiele przyczyn, dla których instancja EC2 nie przejdzie kontroli stanu.Samo sprawdzenie może być niepoprawnie skonfigurowane, grupy zabezpieczeń mogą być błędne lub sama usługa na instancji EC2 może nie odpowiadać tak, jak powinna.

+0

Zajmę się usuwaniem stosu na podstawie tego, co napisałeś, jednak usuwanie środowiska z wewnętrznej łodygi nie powiedzie się za każdym razem, gdy spróbuję ją usunąć. Znalazłem przyczynę problemu i jest to plik konfiguracyjny dodający regułę ingerencji w grupę bezpieczeństwa. Na razie usunąłem ten plik i wygląda na to, że działa. Plik, którego używałem, jest tutaj, nie wiem, dlaczego to się nie udało. https://github.com/FoxxMD/laravel-elasticbeanstalk-queue-worker/blob/master/src/.ebextensions/00supervisordIngress.config –

+0

@JosephCrawford, plik tworzy zasób "AWSEBSecurityGroup", który może już [istnieć] (http : //docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-resources.html). Jeśli ten plik zostanie scalony ze stosem ElasticBeanstalk, dwa zasoby o tej samej nazwie spowodują niezdefiniowane zachowanie. –