|
srebrna: #teammigracyjny Zajebiście jest, bo połączenie się do bazy przez SQL Studio wymaga BRAKU VPN (vpn za bardzo opóźnia), ale nasza aplikacja jest internal, więc żeby macnąć stronkę, muszę się połączyć. |
|
2021/10/05 12:37:31 przez www, 0 ♥
|
|
|
srebrna: #teammigracyjny W związku z tym w trakcie wejścia na preproda odkryliśmy, że NIESPODZIEWANIE konta użytkowników muszą być założone w innym miejscu...! Oraz, nie umieją połączyć aplikacji z bazą... |
|
2021/10/05 12:35:46 przez www, 2 ♥
|
|
|
srebrna: #teammigracyjny Okazuje się, że WBREW WSZELKIM OCZEKIWANIOM na preprodzie jest ZUPELNIE INNA KONFIGURACJA niż na QA i jest ZASKOCZENIE WSZEM I WOBEC. |
|
2021/10/05 12:34:48 przez www, 8 ♥
|
|
|
srebrna: #teammigracyjny We wtorek robimy preprod bazy i nadal nie wiem, czy aplikacja już stoi i czeka na bazę, czy dowiem się pojutrze rano, że dupa, nie mamy wjazdu na foldery w storage (bo jutro mnie nie ma w pracy, nah nah nah) |
|
2021/10/04 00:17:42 przez www, 0 ♥
|
|
|
srebrna: #teammigracyjny Przy okazji, przypomniało mi się - w piątek mieliśmy zrobić deployment na preproda samej APLIKACJI, zeby, prawda, przetestowac czy pliki powchodziły gdzie trzeba. Guess what. |
|
2021/10/04 00:16:45 przez www, 0 ♥
|
|
|
srebrna: #teammigracyjny YAY. Ruch przeszedł. Czyli trzeba dodać nasze własne middleware do konfiguracji DNS tak żeby było uważane za internal. |
|
2021/09/22 14:26:55 przez www, 4 ♥
|
|
|
srebrna: #teammigracyjny Więc MW łączy się z publicznym IP (i przedstawia się sam swoim publicznym). Po czym Azure odrzuca połączenie, bo nasza aplikacja uznaje tylko prywatne wewnętrzne IP za dopuszczone... |
|
2021/09/22 14:18:09 przez www, 0 ♥
|
|
|
srebrna: #teammigracyjny Ahahaha. Jednak DNS, ale w jakże wesoły sposób. Subnet, w którym jest MW NIE JEST uznane przez DNS za internal, więc DNS przekierowuje zapytanie na publiczne, daje publiczny IP Azure... |
|
2021/09/22 14:17:11 przez www, 3 ♥
|
|
|
srebrna: #teammigracyjny Chyba znaleźli kogoś z network teamu, kto umie filtrować ruch sieciowy używając tylko jednego końca. Na razie sprawdzamy, czy coś wychodzi z danego source. Trzymajcie kciuki. |
|
2021/09/22 14:09:08 przez www, 1 ♥
|
|
|
srebrna: #teammigracyjny Więc zapytałam już kilka razy, czy da się GDZIEŚ obadać co FW odrzuca (co odwalił jako 403) bo może, wild guess, IP wychodzące pokazuje się inaczej niż samej maszynie się wydaje, że ma? |
|
2021/09/22 14:03:36 przez www, 2 ♥
|
|
|
srebrna: #teammigracyjny Wygląda na to, że ktoś spierdolił konfigurację gdzieś cichutko i NASZE WŁASNE MIDDLEWARE nie jest uważane za używające naszego wewnętrznego IP i NI CHUJA nie wiadomo czemu i jak. |
|
2021/09/22 14:02:14 przez www, 1 ♥
|
|
|
srebrna: #teammigracyjny Bo na razie sieciowcy upierają się jak licho, że między IP mw i IP Azure nic nie lata, A SERWER ODPOWIADA. To może.... (drumroll) TO NIE SĄ TE IP. |
|
2021/09/22 14:00:28 przez www, 1 ♥
|
|
|
srebrna: #teammigracyjny I ja i człowiek od mw już wiemy, że trzeba zrobić JEDEN test pt "wszystek ruch Z TEGO IP" i DRUGI "wszystek ruch DO TEGO DRUGIEGO IP" i zobaczyć, czy nie mamy dziwnych efektów. |
|
2021/09/22 13:59:33 przez www, 1 ♥
|
|
|
srebrna: #teammigracyjny Wykonaliśmy próbę. middleware pyrgnęło nasz serwer. Serwer odpowiedział "to ja, ale spierdalaj" czyli "403". Ludki od sieci nadal nie widzą ruchy w sieci. Łkam. |
|
2021/09/22 13:57:39 przez www, 1 ♥
|
|
|
srebrna: #teammigracyjny Okazuje się, że na ważnego calla, na którym mamy analizować spierdolinę na połączeniach, ZAPOMNIANO zaprosić kogoś od firewalli. To na fw są logi co może walić 403. SZLOCHAM. |
|
2021/09/22 13:52:30 przez www, 2 ♥
|
|
|
srebrna: #teammigracyjny Bo on jest techniczny a ja z teamu funkcjonalnego i jak ja żądam wsparcia migracji to wg niego bardziej się ludzie wdzwaniają niż jak on organizuje. Aż dziwne. |
|
2021/09/22 12:54:02 przez www, 0 ♥
|
|
|
srebrna: #teammigracyjny Przy okazji wczoraj dowiedziałam się, że jak JA wysyłam zaproszenie a potem kolega V zbiera na nie ludzi, to to ma lepszy wynik niż jak kolega V sam wysyła zaproszenie. |
|
2021/09/22 12:53:21 przez www, 1 ♥
|
|
|
