Logic Apps이 뭐죠?
이 글을 쓰기에 앞서, 우선 Logic Apps 가 뭔지 알아보자.
MS docs 링크!
Logic Apps는 한마디로 손쉽게 사용할 수 있는 no code workflow 생성기(?) 같은 거다.
무슨 말이냐 하면 아래와 같은 요구 사항을 받았었다.
우리 내부에 있는 특정 데이터를, 몇일간만 신규 서비스 모니터링 때매 밖에서 핸드폰으로 조회하고 싶어요!
내가 실제로 받은 요청이다
나도 누군가 마법처럼 해줬으면 좋겠다
이런 요청 사항이 있을때 나의 뇌리속에는 다음과 같은 생각이 반사적으로 스쳐지나간다.
- 어차피 당분간만 사용하고, 내부인원만 접근한다면, 간단하게 power apps 활용해서 정해진 인원만 정해진 query 돌려서 데이터 받아가게 하는게 제일 빠르고 간단하겠는데?
- 내부 데이터라면 이전에 private으로 배포한 flexible 말하는 것 같은데, 그 db public에서 접근 안되지 않나?
- public에서 바로 접근이 안되면 데이터를 조회해줄 proxy 역할 해주는 아이가 필요하겠네
- proxy 역할 할 수 있는 애들 중에 vnet integration으로 내부 resource로 통신 가능하고, 최대한 no code로 공수 쉽게 쓰며 공수가 적게 들어가는 아이는 없나?
위 4번에 가장 부합하는 Azure Service를 꼽으라면 Logic Apps를 추천한다. 정말 쉽고 편리하다.
최대한 쉽게 쓸 수 있으며, no code로 나와 같은 SA들도 충분히 쉽게 쉽게 쓸 수 있는 paas 형 서비스를 찾고 있다면 Logic Apps를 써보자!
우선 Logic Apps를 어떻게 배포할까?
우리는 현재 db 접근 관련해서 조건들이 몇가지 있다.
- 내부 데이터를 밖에서 조회해서 볼 수 있어야 한다.
- DB는 postgresql flexible, private 형태로 배포되어 있다.
위 두가지 조건을 만족 시키려면 App service plan을 물고 있는 여타 서비스들이 가지고 있는 vnet integration을 사용해야 한다. inbound는 public으로 받지만, service으로부터 나오는 outbound traffic은 virtual network 안쪽으로 흐르게 되야 우리 내부 데이터를 볼 수 있다.
어떤 옵션들을 선택해야 할까?
포인트는 3가지로 볼 수 있다.
- public access를 enable 한다.
- network injection을 enable 한다.
- outbound subnet을 선택하여 밟고 갈 서브넷을 설정해준다.
위와 같이 하면, power apps에서 들어오는 트래픽은 받아줄 수 있고, private에 숨어있는 postgresql은 활용할 수 있다.
PostgreSQL 사용하고 싶은데 어떻게 쓸까?
In-App? Shared?
Designer에서 이제 원하는데로 그려나가면 되는데, Logic Apps에서 postgresql에 connection을 열고 연결하는 방법은 크게 두가지 방향이 있다.
위와 같이 In-App과 Shared가 있다.
이 둘의 차이점은 해당 workload가 어디서 구동되냐 이다.
In-App: 내가 생성한 Logic Apps 안에서 돌아감
Shared: Microsoft hosted 환경에서 돌아감
Azure Devops를 경험해 봤다면 selfhosted와 microsoft hosted의 차이라고 보면 쉽게 이해가 갈 것이다.
(Built-in = In-App, Standard and Enterprise = Shared)
위의 내용에서 유추할 수 있듯, 만약 shared workload를 생성해다가 private하게 배포된 나의 postgresql에 접근하려하면 불가능하다.
우리는 In-App의 workload 중 db에 접근할 수 있는 workload를 활용해야 한다.
단순하게 postgresql을 검색하면 아래와 같은 아이가 검색 되지만, 이 아이는 shared 이기에 microsoft가 어디에선가 hosting 해주는 환경에서 구동된다. 즉, 내 postgresql에는 traffic이 도달 될 수 없다.
우리는 In-App에서 db를 연결할 수 있는 workload를 골라야 한다!!!
JDBC
In-App 커넥터에서 사용할 때 아래의 JDBC를 사용했다.
이 connector에 connection 정보를 넣고 내가 사용하고 싶은 쿼리 써서 돌려보면 아래와 같은 오류를 만나볼 수 있다.
위 모자이크 처리된 tracking id를 따라가서 확인해보면, 스크린샷으로 해당 error를 찍진 못했지만 jdbc를 통해서 postgresql 을 열때 jdbc drvier가 없다고 나온다. error를 확인할 땐 kudu를 통해서 아래의 스크린샷과 같은 경로로 따라가서, 각자 만든 Logic Apps의 workflow 이름안에 저장되어져 있다. _(Function까지 공통 경로이고 내 앱의 psql-check-status는 workflow 이름이다.)
사실 이 포스팅은 Logic Apps의 JDBC connector를 통해서 다른 db를 열 때, 나와 같이 오류를 맛본 사람들이 빠르게 문제 해결을 했으면 좋겠다는 목적으로 작성하게 되었다. 미래의 내가 또 같은 부분을 찾아볼 확률도 있기에
먼저 JDBC에 사용될 driver를 받은 뒤, 아래의 경로로 이동하여 준다.
site/wwwroot
이후, 아래의 경로를 생성하여 이동하여 준다.
lib/builtinOperationSdks/JAR/
JAR directory 밑에 jar 형태의 driver를 아래와 같이 업로드한다. 업로드 할 때 jar 자체를 업로드하면 jar가 압축이 풀리며 들어가게 된다. jar파일은 zip으로 한번 감싼다음 업로드 해주자.
업로드 이후 workflow를 돌려보면 더이상 error가 발생하지 않는 부분을 확인할 수 있다.
조금 더 자세한 내용을 원한다면 docs를 활용하자!!
마치며
다른 driver도 위와 동일한 방법으로 추가할 수 있으니, 귀찮을 땐 Logic Apps!!
여담으로, power apps와 잘 연결하여 전달했다. 보안쪽은 app restriction에서 service tag 추가하구 특정 헤더값으로 인증 거친 뒤에 쿼리 결과 값을 power apps로 전달하도록 해놨다.
