'Server/AWS'에 해당하는 글 30건

Tomcat Log - Slack Alarm

Server/AWS 2020. 10. 28. 19:00

톰캣에 특정 키워드가 포함된 에러로그가 발생됐을 때 슬랙으로 알림을 받기 위해 필요한 서비스들은 AWS 의 cloudwatch, sns, lambda 등 이다. 이 서비스들로 과정을 대충 설명하자면...


  • cloudwatch 에 톰캣 로그를 남길 수 있다. 그리고 특정 키워드들의 필터링이 가능하다. 필터링 됐을때 경보(알림)이 가능하다.
  • 경보 설정에서 SNS 로 알림을 전송할 수 있다.
  • SNS 에 알림이 오면 슬랙에 메시지를 전달하는 Lambda 함수를 실행하게 하면 끝.



EC2 로그를 cloudwatch 로...

지표 필터(Metric Filter) 생성

경보를 처리할 SNS(Simple Notification Service) 생성

경보(Alarms) 생성

슬랙 웹훅(WebHooks URL) 생성

람다(Lambda) 생성



1. EC2 로그를 cloudwatch 로...


EC2 의 특정 로그를 cloudwatch 로 전달하기 위해서는 awslogs 가 설치되어 있어야 한다.

아래는 centos7 에서의 설치 및 설정 예이다. (OS 별로 설치 방법은 다름.)


# yum install awslogs
No matches found
 
# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
 
# python ./awslogs-agent-setup.py --region ap-northeast-1
AWS Access Key ID [None]: ********************
AWS Secret Access Key [None]: ****************************************
 
Path of log file to upload: /var/log/tomcat8/api.log
Destination Log Group name: /project1/var/log/tomcat8/api.log
 
Timestamp format: 3. %Y-%m-%d %H:%M:%S (2008-09-08 11:52:54)
cs


curl 로 다운받아 setup 파일을 리전과 함께 실행하면 IAM 및 로그 관련 설정을 하게 된다.

AWS Key 는 CloudWatch Logs 에 대한 권한이 있는 IAM 정보를 적으면 되고, 

EC2 의 어떤 로그 파일을 cloudwatch 로그 그룹으로 생성할 것인지 를 적으면 되고,

로그 파일의 datetime_format 을 선택하면 된다.


위에 설정한 항목들은 /var/awslogs/etc/awslogs.conf 파일에서 수정 및 추가가 가능하다.


...
[/var/log/tomcat8/catalina.log]
datetime_format = %d-%b-%Y %H:%M:%S
file = /var/log/tomcat8/catalina.*.log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /project1/var/log/tomcat8/catalina.log
 
[/var/log/tomcat8/web.log]
datetime_format = %Y-%m-%d %H:%M:%S
file = /var/log/tomcat8/web.log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /project1/var/log/tomcat8/web.log
...
cs


설정을 마쳤으면 awslogs 데몬을 올리고 부팅시 시작되도록 설정한다.


# systemctl start awslogs
# chkconfig awslogs on
cs


여기까지 마쳤다면 cloudwatch log-group 에서 catalina.log 등의 로그를 확인할 수 있다.


설정 중 datetime_format 의 형식대로 로그의 라인을 구분하므로 이 부분을 정확하게 선택하지 않으면 cloudwatch 에서 로그를 볼 수 없을 것이다. 만약 awslogs 데몬이 시작된 후에도 cloudwatch 에 로그가 생성되지 않았다면 /var/log/awslogs.log 파일에서 에러 로그를 확인한다.



2. 지표 필터(Metric Filter) 생성


cloudwatch 특정 로그의 [지표 필터] 탭에서 지표 필터를 생성한다.


우리의 목적은 로그에서 에러 문구를 추출하는 것이므로 [패턴 필터링] 항목에는 필터링할 키워드를 나열한다. error 나 exception 등 원하는 것들을 나열하고 [패턴 테스트] 항목에서 테스트를 할 수 있다. (아래 예에서는 ERROR, Error, error 라는 키워드를 필터링 하였다.) 지표의 세부 정보까지 입력하면 지표 필터가 생성고, 이것은 cloudwatch 의 경보(Alarms) 에서 사용될 것이다.



3. 경보를 처리할 SNS(Simple Notification Service) 생성


SNS 메뉴의 토픽을 표준(standard) 및 default 설정으로 하나 생성한다.

이 토픽은 경보를 받아 람다로 전달될 것이다.



4. 경보(Alarms) 생성


다시 cloudwatch 의 경보(Alarms) 로 돌아와 경보를 생성한다. 이미 생성한 지표를 선택하고 1분안에 에러가 발생한다면, 이미 생성한 SNS 토픽으로 전달하도록 설정한다.



5. 슬랙 웹훅(WebHooks URL) 생성


특정 채널로 메시지를 전달 받기 위해서는 슬랙에서 별도의 WebHooks 를 생성하고 람다에 입력해 주어야 한다.

슬랙앱에서 [Administration]-[Manage Apps] 를 클릭하면 브라우저로 Manage 페이지가 열린다.

webhooks 이 없다면 상단 App 검색창에서 검색하여 [Incoming WebHooks] 를 install 하고 [Add to Slack] 을 클릭하여 WebHooks 를 생성한다.



Post to Cannel 항목에는 메시지를 전달받을 채널을 선택하면 되고 Webhook URL 은 람다에 입력해야 하므로 기록해 놓는다.




6. 람다(Lambda) 생성


SNS 에 알림이 발생하면 실행될 람다를 생성한다.

함수 생성 - Blueprints :  cloudwatch-alarm-to-slack-python  를 선택.

구독할(위에 생성한) SNS 를 선택하고 약간의 코드 수정, 환경 변수 추가만 하면 슬랙으로 알림을 보낼 수 있다.


import boto3
import json
import logging
import os
 
from base64 import b64decode
from urllib.request import Request, urlopen
from urllib.error import URLError, HTTPError
 
 
# The base-64 encoded, encrypted key (CiphertextBlob) stored in the kmsEncryptedHookUrl environment variable
#ENCRYPTED_HOOK_URL = os.environ['kmsEncryptedHookUrl']
# The Slack channel to send a message to stored in the slackChannel environment variable
#SLACK_CHANNEL = os.environ['slackChannel']
 
#HOOK_URL = "https://" + boto3.client('kms').decrypt(
#    CiphertextBlob=b64decode(ENCRYPTED_HOOK_URL),
#    EncryptionContext={'LambdaFunctionName': os.environ['AWS_LAMBDA_FUNCTION_NAME']}
#)['Plaintext'].decode('utf-8')
 
HOOK_URL = os.environ['HOOK_URL']
 
logger = logging.getLogger()
logger.setLevel(logging.INFO)
 
 
def lambda_handler(event, context):
    logger.info("Event: " + str(event))
    message = json.loads(event['Records'][0]['Sns']['Message'])
    logger.info("Message: " + str(message))
 
    alarm_name = message['AlarmName']
    #old_state = message['OldStateValue']
    new_state = message['NewStateValue']
    reason = message['NewStateReason']
 
    slack_message = {
        'text'"%s state is now %s: %s" % (alarm_name, new_state, reason)
    }
 
    req = Request(HOOK_URL, json.dumps(slack_message).encode('utf-8'))
    try:
        response = urlopen(req)
        response.read()
        logger.info("Message posted")
        #logger.info("Message posted to %s", slack_message['channel'])
    except HTTPError as e:
        logger.error("Request failed: %d %s", e.code, e.reason)
    except URLError as e:
        logger.error("Server connection failed: %s", e.reason)
cs


생성된 코드에서 기존 환경 변수인 kmsEncryptedHookUrl 과 slackChannel 을 사용하지 않고 HOOK_URL 을 직접 사용하는 코드로 변경한 것이다. 코드 수정 후 환경 변수 항목에 HOOK_URL 이름으로 WebHooks URL 을 입력하면 완성이다.


이제 톰캣 로그에 ERROR, Error, error 등의 키워드가 표시되면 슬랙으로 아래처럼 알림이 발송될 것이다.




로그 상세를 알람 메시지에 표시하고 싶었지만... 불가...




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CloudFront

Server/AWS 2019. 8. 20. 18:43



CloudFront 는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 AWS 의 CDN 서비스이다. 전 세계 주요지역에 CloudFront POP(엣지 로케이션) 이 위치하고 있어 해당 캐시 서버에서 오리진(EC2 인스턴스나 ELB, S3 버킷 등) 의 파일을 받아 클라이언트에게 빠르게 응답하는 기능을 한다. 캐시 서버는 오리진(origin)으로부터 파일을 캐시하고 나면 해당 파일이 수정되기 전까지는 오리진에 연결하지 않고 빠르게 클라이언트에 응답할 수 있다. 


CloudFront 는 이미지나 동영상 등의 리소스가 보관된 S3 를 오리진으로 설정하는 것이 일반적이며, 운영시 꼭 필요한 서비스 중 하나이다.



CloudFront 의 설정/배포 방법


  1. CloudFront 에 캐시할 오리진(예제에서는 S3 사용) 의 주소(test.s3.amazonaws.com) 메모.
  2. 콘솔의 CloudFront 에서 [Create Distribution] 으로 배포 설정.
  3. Origin Domain Name 의 S3/ELB 목록에서 캐시할 오리진을 선택하고 Alternate Domain Names(CNAMEs) 에 원하는 CloudFront 도메인 설정.
  4. 나머지 설정은 버킷 접근 권한/정책, https, SSL 설정 정도... 이렇게 세팅하고 배포 생성하기를 시작하면 수분안에 각 캐시 서버에 오리진이 배포된다.


CloudFront 배포 도메인은 http://aabbccdd112233.cloudfront.net 형식이며 설정한 CNAME 으로 대체할 수 있다. 브라우저에서 해당 리소스의 헤더에서 X-Cache: Hit from cloudfront 가 확인되면 정상적으로 캐시되고 있는 것이다. 캐시 유지 시간이 지나서 CloudFront가 오리진에 접속하여 파일을 가져왔을 때에는 Miss from cloudfront 라고 표시된다.



캐시 삭제


캐시 파일은 기본적으로 24시간 동안 유효하며, 특정 파일을 즉시 갱신해야 할 경우 콘솔 등에서 무효화(Invalidation) 요청을 통해 캐시된 파일을 삭제시킬 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Amazon EKS

Server/AWS 2019. 5. 18. 00:56


Amazon EKS 는 AWS 에서 Kubernetes 를 손쉽게 실행하도록 하는 관리형 서비스이다. EKS 는 여러 가용 영역에서 Kubernetes 제어 플레인 인스턴스를 실행하고 관리하여 고가용성을 보장한다. 또한 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 의 모든 기존 플러그인과 도구를 사용할 수 있다. EKS 는 ECR, ELB, IAM, VPC 등의 AWS 서비스와도 통합되어 확장성과 보안을 제공한다. 아래는 EKS 를 사용하여 어플리케이션을 배포하는 일련의 플로우이다.


  1. 클러스터의 VPC / IAM / Security Groups 생성
  2. 로컬에 AWS CLI / kubectl / IAM Authenticator 설치
  3. EKS 클러스터 생성
  4. kubeconfig 파일 생성 / 설정
  5. Node 생성 및 클러스터에 등록
  6. kubectl 로 클러스터와 통신
  7. EKS 클러스터에 어플리케이션 배포 및 관리


우선 EKS 는 EC2 등으로 쿠버네티스 마스터 노드를 따로 띄우지 않고 AWS 에서 관리해 준다. 물론 유료지만 마스터 노드 설정이 따로 필요 없고 단지 클러스터만 생성하면 된다. 그럼에도 불구하고 추가로 해야할 일이 꽤나 많은 것처럼 보여진다. 하지만 살펴보면 기존 EC2 같은 컴퓨팅에도 사용했던 것들이니 혼란스러울 것은 없다. Hello EKS 를 만들어보기 전에 일단 EKS 가 어떻게 돌아가는지를 위 플로우와 함께 설명해 보려 한다.


먼저 클러스터를 생성할 때 지정해야 할 항목들로 VPC, SG(Security Group), IAM 이 있다. 그렇기 때문에 미리 생성해 놓아야 한다. VPC 와 SG 는 원하는 구성이 있다면 미리 생성하여 사용해도 좋고, aws 에서 샘플로 제공하는 기본 사양을 그대로 사용하거나 수정하여 사용할 수 있다. 일반적으로 EKS 의 VPC 구성은 public 서브넷에 마스터 노드, private 서브넷에 워커 노드를 배치하는 형태를 가진다. 또한 클러스터의 제어 플레인에 리소스 권한을 부여하기 위해 IAM role 을 미리 생성해 놓고 클러스터 생성시 지정해야 한다. 일단 이렇게 하면 클러스터 및 제어 플레인이 생성된다. 그리고 바로 제어 플레인 사용 과금이 시작된다.^^ 여기까지가 1,3번 과정.


이제 노드를 추가해보자. EKS 콘솔에 들어가보면 알겠지만 관련 메뉴가 [클러스터 리스트] 하나 달랑 있다. EKS 콘솔에서 할 수 있는건 클러스터 생성/설정까지만... EKS 에서 노드는 일반적으로 EC2를 가리킨다. 그렇다면 노드 생성은 일반적인 EC2 생성하듯 하면 될 것 같지만 그 외에도 설정해야 할게 상당히 많다. AutoScalingGroup 설정, 연결할 클러스터 세부 설정 등 꽤나 복잡하다. 하지만 AWS 에서는 CloudFormation 에서 미리 정의된 소스들을 사용하여 노드 생성/설정 및 클러스터 등록을 간편하게 할 수 있다. 클러스터 등록할 때 부터는 kubectl 을 사용하게 되는데 특정 클러스터와의 연결을 위해 IAM 인증이 필요하므로 둘다 로컬에 미리 설치해 놓도록 한다. 여기까지가 2,4,5,6번 과정.


7번 과정은 배포 방식에 따라 설정은 다르겠지만 기본적으로 어플리케이션을 컨테이너 이미지로 생성하여 업로드하고 yaml/json 파일로 deployment, service 등을 설정하여 배포할 수 있다. 그 뒤 유지보수는 대시보드 등으로...


하나마나인 설명 같기도 하고;; 다음엔 Hello EKS 를 직접 만들어보긔~




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

AWS VPC 시나리오

Server/AWS 2019. 5. 17. 11:54

AWS 에서 VPC 마법사로 생성할 수 있는 VPC 시나리오로 다음의 4가지를 제공한다.

public 서브넷만 있는 VPC

public 및 private 서브넷이 있는 VPC

public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

private 서브넷만 있고 VPN 액세스를 제공하는 VPC


이 4가지의 VPC 구성을 알고나면 어떤 커스텀 VPC 구성도 가능하다. 하나씩 살펴보자.



1. public 서브넷만 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

ec2 : 10.0.0.6 (EIP: 198.51.100.2)

router : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

internet gateway

ec2 가 인터넷에 오픈되어 있는 웹서비스 등에 알맞는 구성이다. 서브넷은 모두 private 형태이므로 외부와의 통신이 가능하려면 internet gateway 를 두어야 하며, 나가는 트래픽에 대하여 routing table 에 올바르게 설정해야 한다. 10.0.0.0/16(local) 은 해당 vpc 의 다른 서브넷으로의 통신을 가능하게 하며, 0.0.0.0/0(igw-id) 는 외부 모든 트래픽은 igw-id 로 보낸다는 설정이다. 외부에서 해당 서비스(EC2 등) 에 접근할 수 있도록 Public IP 주소도 연결해야 한다. Public IP 주소가 없다면 외부로부터 요청을 받을 수가 없을 것이고, router 에 igw 로의 설정이 없다면 외부로 응답이나 요청을 할 수 없을 것이다. 보안적인 측면에서 보안그룹(security group) 과 network acl 로도 ip/port 에 대하여 허용/거부를 설정할 수 있는데 network acl 은 보통 다 열어놓고 보안그룹만 이용한다. 모든 포트가 차단된 상태에서 웹서비스시 80, 443 포트로 들어오는 요청은 모두 열어주고, 22 포트는 개발자 ip 정도만 열어주는 형태를 추천한다. 이것이 일반적인 public 서브넷의 형태이다. 



2. public 및 private 서브넷이 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(nat-gw-id)

internet gateway

nat gateway

프론트엔드와 백엔드로 나누어 일반적으로 웹서버만 public 서브넷에 두고 DB 는 private 서브넷에 두어, 외부에서는 웹서버와 접근 가능하게 하고 DB 는 웹서버에서만 접근 가능하게 하는 구성이다. 굳이 노출할 필요없는 백엔드를 외부와 차단시키는 것에 중점을 둔 구성이다. public/private 구분을 위해 igw(인터넷 게이트웨이) 로 향하지 않도록 router 를 하나 더 추가해야 한다. 옵션이지만 private 서브넷에서 일방적으로 외부와 통신을 해야 한다면 nat 게이트웨이를 생성하고 router 에 nat 게이트웨이로 트래픽을 보내도록 routing 을 추가한다. igw 가 public 서브넷과 외부와의 양방향 통신이 가능하게 한다면, nat 게이트웨이는 public 서브넷에 위치하면서 private 서브넷에 대하여 외부로 단방향 통신(요청/응답) 이 가능하게 하며 응답을 받을 수 있도록 public IP 할당이 필요하다. 외부에서는 여전히 nat 게이트웨이로 서브넷과 통신할 수 없다. (nat 게이트웨이는 유료) 웹서버의 보안그룹 설정은 시나리오1과 동일, DB 보안그룹 설정은 웹서버 보안그룹ID 로부터 오는 해당 DB 전용포트만 열어주면 된다. 예로 mysql 의 경우 3306 포트.



3. public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

internet gateway

vpn (virtual private gateway, customer gateway)

시나리오2번과 비슷하지만 private subnet 을 외부는 여전히 차단하고 특정 네트워크(customer gateway)와만 통신할 수 있도록 하는 구성이다. vpn 이라고 하는 가상 비공개 네트워크를 구현하여 vpn 에 연결되어야만 private subnet 과의 통신이 가능하다. vpc 콘솔에서 private 서브넷과 연결할 네트워크(customer gateway) 를 ip 와 함께 지정하고 virtual private gateway 생성, 그리고 그 둘을 이어주는 Site-to-Site VPN 연결을 구성하면 된다. (vpn 도 역시 유료) 서브넷의 보안그룹 설정은 vpn 으로 연결되는 네트워크 ip 대역으로부터 필요한 포트만 열어주면 된다.



4. private 서브넷만 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

private subnet : 10.0.0.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

router : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

vpn (virtual private gateway, customer gateway)

시나리오3번에서 public 서브넷만 제외한 구성이다. public 서브넷이 없으므로 igw 도 없다. vpn 과 연결된 특정 네트워크에서만 private 서브넷과 통신이 가능하며, 외부가 차단된 구성이다보니 서비스보다는 사내 인트라넷이나 개발 서버 등이 필요할 때 사용 가능한 구성이다.


이 중에 그나마 유용하게 쓸 수 있는 것이 2번이나 3번 시나리오 이다. 내가 선호하는 구성은 소규모 웹서비스의 경우 2번과 흡사하게. 더 큰규모의 웹서비스는 3번 시나리오에서 public subnet 에는 elb 만 두고 모든 자원을 private 서브넷으로, private 서브넷은 vpn 연결로 관리하는 것이 즐겨 사용하는 시나리오 이다. ^^


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeStar

Server/AWS 2018. 9. 17. 21:31

특정 프로그래밍 언어로 개발/빌드/배포 환경을 미리 구성된 템플릿을 사용하여 빠르게 구축해 주는 서비스이다. 예를 들어, Laravel 로 PHP 개발을 하려 한다면, EC2 / Git / CodeBuild / CodeDeploy / CodePipeline 등을 미리 구성해 주며 git 에 push 만 하면 자동 배포되어 결과를 확인할 수 있다. 그리고 제공되는 대시보드에서 프로젝트의 개발/빌드/배포 등의 이벤트 현황을 즉시 확인할 수 있다. 아무래도 미리 준비된 템플릿으로 빠르게 구성되는 장점은 있지만, 언어나 프레임워크의 버전, 서버종류 등의 선택이 제한적인 단점 때문에 사용할 일이 있을지는 모르겠다.





CodeStar 는...


CodeStar 는 AWS 를 기반으로 애플리케이션을 빠르게 개발, 빌드, 배포할 수 있는 클라우드 기반 서비스이다. CodeStar 프로젝트를 생성하면 이미 만들어진 CloudFormation 템플릿 중 원하는 환경의 어플리케이션을 선택할 수 있다. 사용되는 Service 들이 모두 리전 별 서비스이므로 CodeStar 역시 리전 별로 서비스한다. CodeStar 자체는 무료이므로 함께 사용하는 리소스의 요금만 발생된다.



CloudFormation 템플릿 선택사항


  • Application : Web application / Web service / Static Website / AWS Config Rule
  • Service : Elastic Beanstalk / EC2 / AWS Lambda
  • Language : Python / PHP / C# / Node.js / Ruby / Java / Go / HTML


Web application 와 Web service 의 차이라면 Web application 은 UI 나 웹페이지 기능이 많고, Web service 는 RESTful 같은 API 기능에 특화되어 있는 것 같다. 그 외에도 빌드가 트리거 될 AWS CodeCommit 나 GitHub 중 하나의 저장소를 선택해야 하고, 리소스 구성 세부 정보에서 배포될 EC2 와 VPC, Subnet 등을 설정할 수 있다.


CodeStar 에는 프로젝트, 도구 체인 및 중요 이벤트를 전체적으로 보여주는 대시보드를 제공한다. 최신 프로젝트 활동 모니터링, 코드 변경, 빌드 결과 및 배포 상태 추적 같은 작업을 타일에 추가/제거하여 대시보드를 구성할 수 있다. 프로젝트를 생성하면 팀의 소유자로 추가되며, 다른 사용자를 더 추가하고 역할을 부여하여 함께 운용할 수 있다. GitHub 리포지토리나 Atlassian JIRA 같은 AWS 외부의 리소스를 사용하는 경우, 사용자 이름 및 이메일 주소를 가진 별도의 사용자 프로필을 사용할 수 있다. 코드를 변경하고 저장소에 푸시하면, Continuous deployment 타일에 진행 중인 작업이 표시되며, CodePipeline 에서 저장소의 변경 사항으로 빌드 및 배포되어 엔드포인트에서 결과를 확인할 수 있다.


프로젝트를 삭제하면 관련 내부 리소스는 자동으로 모두 삭제된다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret