역운 발전

LAMP Stack 시대에 로컬 웹 개발은 매우 간단했다.당신의 기계에 코드 복사본이 있고 로컬 서버를 시작할 것입니다. 예를 들어 rails server.복잡성과 코드 라이브러리의 증가에 따라, 우리는 Docker에게 도움을 청했다. Docker는 우리를 지옥에서 구해내겠다고 약속했다.서비스에 대한 체계 구조가 보급됨에 따라 평균 백엔드의 서비스 수량이 급증하면서 이 문제는 더욱 복잡해졌다.
서버가 없는 세계에서 로컬 시뮬레이션을 통해 서버가 없는 응용 프로그램을 구축하는 데는 몇 가지 단점이 있다.현지에서 대량의 서로 다른 서비스를 모의하기 어렵다. 이런 서비스는 자주 새로운 기능을 얻는다. 오프라인 모의 도구는 보통 지역사회에서 유지보수한다. 이것은 새로운 기능이 클라우드 컴퓨팅 상대보다 뒤떨어지고 누군가가 당신을 좋아할 때까지adds them.
실시간 AWS 환경과 로컬 에뮬레이터 사이의 차이는 매우 크다.IAM 정책은 클라우드에서만 테스트할 수 있습니다.로컬에는 제한 시간 및 메모리 제한이 없으며 VCPU 또는 콜드 부팅도 없습니다.특히 곤혹스러운 것은 설정 고장으로 인해 기능이 실행되지 않거나 전혀 실행되지 않을 수도 있다는 것이다!
예를 들어 serverless offline, SAM local와 architect framework 등 아주 좋은 도구가 있지만 클라우드 개발 환경을 다른 방법으로 고려할 것을 제안합니다.
노트북에서 클라우드를 모의하는 것은 취약하고 기능이 부족하며 질서를 유지하기 어렵다. (특히 신입 개발자에게는)AWS의 엔지니어 대군을 따라잡기 위해 노력하기보다는 각 기능의 스택, 공유 데이터 접근과 빠른 배치를 통해 로컬 시뮬레이션을 완전히 대체하는 방법을 살펴보자.
우리가 좋아하는 서버 없는 기술의 한 가지는 서버, 배치, 테이블의 수량을 기반으로 하는 것이 아니라 사용에 따라 비용을 지불하는 것이다.이것은 우리가 매일 10000개의 요청을 수행하는 창고가 있거나, 매일 1000개의 요청을 수행하는 창고가 10개가 있다는 것을 의미한다. 최종 계산서는 같다.게다가 아낌없는free tier까지 개발자마다 다른 서버 없는 응용 사례를 설정하는 것은 거의 힘들지 않다.이 아이디어를 한층 더 깊이 있게 하고, 사용자가 사용하는 모든 기능에 새로운 창고를 만들 수 있도록 격려합니다.나는 각 지점마다 창고를 하나씩 쌓는 것이 좋은 시작이라고 건의한다.
서버 없는 프레임워크(그리고 대부분의 다른 프레임워크를 사용하지만 본고는 주로 서버 없는 프레임워크를 주목한다)를 사용하여 새로운 창고를 만드는 것은 매우 간단하다.새 단계 이름만 지정하고 서버 없는 배포를 실행하면 됩니다.

sls deploy --stage my-new-feature

현재 우리는 완전히 격리된 창고에서 우리의 새로운 특성을 구체적으로 테스트할 수 있다.
그러나 이로 인해 우리는 두 가지 문제에 직면하게 되었다. 그것이 바로 클라우드 로컬 서버 개발이다.데이터 저장소에 대한 접근은 매우 느리다.
모든 특성에 새로운 창고가 있는 것은 매우 좋지만, 때때로 우리는 장기적으로 존재하는 환경 (개발, 등장, 통합 등) 과 현지 환경 사이에서 자원을 공유하기를 희망한다.일반적으로, 우리는 공유 데이터베이스에서 모든 기능 창고를 실행하는 것을 더욱 좋아한다.특히 Single Sheet 설계 서비스의 경우 설정하려면 API 호출이 여러 번 필요할 수 있습니다.DynamoDB 테이블 같은 것에 대한 접근을 창고 사이에서 어떻게 공유합니까?
우리는 serverless.yml 템플릿의 변수를 통해 이 점을 실현할 수 있다.만약에 우리가 스테이지dev가 있는데 그 안에 다이나마이트 DB표가 포함되어 있다면 우리는 기능 분기my-new-feature를 처리할 때 그것을 사용하기를 희망한다.이 솔루션은 사용자가 prod 및 dev의 단독 AWS 계정을 사용하지만 기능 스택을 dev 계정에 배치한다고 가정합니다.다른 설정이 있을 경우 이 솔루션은 계속 적용될 수 있지만 IAM을 통한 계정 간 자원 액세스에 대해 더 복잡한 액세스 제어 논리를 추가해야 할 수도 있습니다.custom 섹션의 이 모듈을 보십시오.

// Create the boolean
custom:
  dynamoTableMap:
    dev: dev-table
    prod: prod-table
    other: dev-table // This will cause non dev or prod stages to use the dev table.
    // You can add more stage exclusions/specifications here
  dynamoTableName: ${self:custom.dynamoTableMap.${opt:stage}, self.dynamoTableMap.other}

// Permissions
iamRoleStatements:
  - Effect: Allow
    Action:
      - dynamodb:Query
      - dynamodb:Scan
      - dynamodb:GetItem
      - dynamodb:PutItem
      - dynamodb:UpdateItem
      - dynamodb:DeleteItem
      - dynamodb:BatchGetItem
    Resource:
      [
        'arn:aws:dynamodb:*:*:table/${self:custom.dynamoTableName}',
        'arn:aws:dynamodb:*:*:table/${self:custom.dynamoTableName}/index/*',
      ]

// Define the resource. Not necessarily required if you provisioned this in a separate stack
// But I left it here for completion
Resources:
    DynamoTable:
      Type: AWS::DynamoDB::Table
      DeletionPolicy: Retain
      Condition: SkipRetained
      Properties:
        TableName: ${self:custom.dynamoTableName}

이 예에서는 DynamoDB 테이블을 지정하지만, 모든 자원일 수 있습니다.그리고 Stage name으로 맵을 볼 수 있는 조건을 정의합니다.일치하는 항목이 없으면 dev표로 돌아갑니다.현재, 새로운 기능 창고를 배치할 때, 공유된 dev표에서 읽고 쓸 것입니다.
이것은 항상 우리가 원하는 것이 아니다. 왜냐하면 어떤 경우, 우리는 DynamoDB 흐름에 의존해서 Lambda 함수를 촉발할 수 있기 때문이다.이러한 상황에서, 우리는 기능 창고에 특정한 새 테이블을 만들고 필요한 데이터를 불러오기를 희망합니다.
그래서 우리는 데이터 공유 문제를 해결했다.그러나 운행serverless deploy을 한 사람이라면 누구나 클라우드 형성이 매우 느릴 수 있다는 것을 안다.우리는 로컬 네트워크 서버에서 얻은 것처럼 즉각적인 피드백에 익숙하다.긴 시간, 몇 분 동안의 배포가 없다면 어떻게 신속한 배포와 신속한 피드백을 얻을 수 있습니까?
입력serverless deploy function.이것command은 update function code API 호출을 이용하여 완전한 구름 형성 배치를 건너뛰고 새로운 zip 파일을 Lambda에 업로드합니다.이것은 훨씬 빨라서 보통 3-5초가 걸린다.만약 우리가 AWS 자원이나 기능 설정을 수정한다면, 우리는 여전히 완전한 serverless deploy 를 실행해야 하지만, 우리의 습관적인 빠른 개발, 교체, 배치 주기 serverless deploy function 는 매우 좋은 해결 방안이다.
다음은 time로 실행되는 데모입니다.

(Gifhere)
완전한 오프라인 체험을 복제할 때 우리는 마지막 하나가 부족하다. 그것이 바로 흐르는 로그다!로컬 서버를 통해 모든 요청을 콘솔에 직접 보냅니다.
Lambda는 CloudWatch에 의존해서 로그를 가져옵니다. 우리는 AWS 컨트롤러로 가서 우리의 최신 요청이 나타날 때까지 페이지를 새로 고칠 수 있습니다.하지만 달리기는 훨씬 쉽다.

serverless logs --function myFunctionName --stage my-new-feature

이 명령은 CloudWatch에서 AWS SDK를 사용하여 로그 흐름 데이터를 가져와 터미널로 직접 전송합니다.내가 개발, 교체, 배치 주기에 일을 할 때, 나는 항상 터미널에서 내 코드와 함께 놓고 실행한다. serverless deploy function다음은 전체적인 모양새입니다.
마지막으로, 나의 기능이 생산에 통합될 준비가 되었을 때, 나는 나의 기능 창고와 내가 설정한 모든 자원을 쉽게 삭제할 수 있다. serverless remove --stage my-new-feature대부분의 무서버 인프라는 사용에 따라 비용을 지불하기 때문에 아마도 나에게 몇 푼의 돈(보통 무료)만 썼을 것이다. 내가 기능 창고를 얼마나 오래 유지하든지!
처음에 클라우드 기반의 무서버 개발 작업 흐름을 사용하는 것은 까다로운 심리 상태 변화일 수 있다.그러나 모든 기능 창고, 공유 데이터 접근과 초고속 배치 + 로그를 통해 우리는 가능한 모든 클라우드 서비스를 모의하지 않고 로컬 작업 흐름에 진정으로 접근할 수 있다.
사상메모 남겨주세요!만약 네가 이것을 좋아한다면 나와 나를 찾을 수 있다blog