Add NLB capability to MCIS

[seokho-son]

Add NLB capability to MCIS

[seokho-son]

@jihoon-seo
1단계: CB-SP NLB관련 동작 현황 파악 및 API 테스트
및 MCIR 등과 마찬가지로, Spider의 API의 기능을 TB 단위 기능으로 올리는 작업을 부탁드려도 될까요?

• TB API 생성 (우선: Create NLB, List NLB, Get NLB, Delete NLB // 향후: 나머지 add remove health 등)
• TB NLB 오브젝트 생성

일단 MCIS의 형상을 크게 고려하지 않고 진행해도 될 것 같습니다.

SP: Create NLB

SP API를 기준으로 대략 생각해본, TB NLB 생성 요청 struct의 예시 입니다.

{
    "ConnectionName": "aws-ohio-config",
    "ReqInfo": {
                        "Name": "spider-nlb-01", (TB의 NLB 객체 ID와 동일)
                        "VNetID(VPCName)": "vpc-01", (TB vNet을 입력하면, SP VPCName으로 전달)
                        "Type": "PUBLIC", 
                        "Scope": "REGION",
                        "Listener": {
                                "Protocol" : "TCP",
                                "Port" : "22" 
                        },
                        "VMGroup": {
                                "Protocol" : "TCP",
                                "Port" : "22", 
                                "VMs" : ["vm-01", "vm-02"] (TB VMID를 입력하면, SP VPC Name으로 전달),
                                "MCIS" : "tb-mcis01" (Spider의 Struct에 없는 필드이며, VM아이디를 생성하기 위한 인자임)
                        },
                        "HealthChecker": {
                                "Protocol" : "TCP", 
                                "Port" : "22", 
                                "Interval" : "10", 
                                "Timeout" : "-1", 
                                "Threshold" : "3" 
                        }
    }
}

나머지 값들은 아직 상세 설정이 가능한 단계가 아니므로
default 값으로 지정하고, 사용자 입력은 가능하도록 처리하면 되겠습니다.

---

TB NLB 메타데이터 struct는
SP: Get NLB
의 형상을 nested 형태로 가급적 유지하여, 향후 SP의 struct 변경시에도 쉽게 변경할 수 있도록 처리하면 어떨까 싶습니다.

[jihoon-seo]

[NLB 자원의 scope]
TB의 NLB 자원은 다음의 두 가지 중 하나 (또는 이외의 옵션) 로 정의할 수 있을 것 같은데,
어떤 것이 더 적합하다고 보이시나요? 😊

1. 다른 MCIR (vNet, SG, ...) 등과 동일하게
   namespace 범위의 자원이며
   특정 MCIS에 속하지는 않음
2. 특정 MCIS에 속함

[seokho-son]

[NLB 자원의 scope] TB의 NLB 자원은 다음의 두 가지 중 하나 (또는 이외의 옵션) 로 정의할 수 있을 것 같은데, 어떤 것이 더 적합하다고 보이시나요? 😊

1. 다른 MCIR (vNet, SG, ...) 등과 동일하게
   namespace 범위의 자원이며
   특정 MCIS에 속하지는 않음
2. 특정 MCIS에 속함

@jihoon-seo 질문 감사합니다. :)

• 일단, Spider에서 정의한 NLBInfo struct와 API (현재)를 고려하면,
  TB 기준, vNet은 NLB와 필수적으로 연계해야 할 것으로 판단하고 있습니다.
  vNet은 Namespaced 리소스이므로, NLB도 마찬가지로 (Namespaced 리소스로) 다루게 될 것 같습니다.

• 리소스 오브젝트 자체를 특정 MCIS에 속하도록 처리할 필요는 없을 것 같습니다. (실제로 내부적으로는 VM들에 의해 연계가 됩니다.) 다만, 고아 리소스(ex: vNet은 삭제되었는데, NLB는 삭제되지 않았다든지, NLB에 등록된 VM이 삭제되었는데 NLB 오브젝트에는 여전히 포함되어 있든지)가 생성되지 않도록 유의할 필요가 있겠습니다.

API: https://documenter.getpostman.com/view/9027676/UzQypiBx

type NLBInfo struct {
        IId             IID     // {NameId, SystemId}
        VpcIID          IID     // {NameId, SystemId}

        Type            string  // PUBLIC(V) | INTERNAL
        Scope           string  // REGION(V) | GLOBAL

        //------ Frontend
        Listener        ListenerInfo

        //------ Backend
        VMGroup         VMGroupInfo
        HealthChecker   HealthCheckerInfo

        CreatedTime     time.Time
        KeyValueList []KeyValue
}

[seokho-son]

@jihoon-seo

NLB ID와 vmGroup ID를 동일하게 하여, (NLB Name을 입력 받지 않고, vmGroup ID를 NLB ID로 자동 처리)
향후 vmGroup에 연계된 NLB를 쉽게 찾을 수 있도록 처리하면 어떨까요?