serverless next.js
v3.7.0
aws lambda@edge의 전체 기능 패리티를 목표로하는 aws lambda@edge의 제로 구성 다음.
현재 지원되는 기능 목록에 대한 기능을 검토하십시오.
켈 이 readme는master브랜치의 최신 변경 사항을 반영합니다. NPM의latest(안정) 또는alpha릴리스에 게시 될 수도 있고 아직 출판되지 않을 수 있습니다. 릴리스로 이동하여 사용중인 올바른@sls-next/serverless-component버전을 찾은 다음 해당 릴리스에 대한 readme를 열어보다 정확한 정보를 얻으십시오. 이 readme에 기능이 나열되어 있지만 작동하지 않는 경우 먼저 NPM에서 가장 최근의alpha릴리스로 업그레이드하십시오.
프로젝트가 GA 이전에 시작되었으므로 현재 Serverless 구성 요소 베타 (GA 버전이 아님)를 사용하고 있습니다. 우리는 현재 배포가 미래에 어떻게 작동하는지 재 작업하고 있으며 CDK, CDK 용 Terraform 등과 같은 더 나은 IAC 솔루션을 탐색하고 업데이트에 대해 연말 전에 발표 할 것입니다.
Next.js 8.0 이후, 서버리스 모드가 도입되어 새로운 저수준 API가 제공되는 새로운 저수준 API를 제공하는 이와 같은 프로젝트가 다른 클라우드 제공 업체에 배포 할 수 있습니다. 그러나 Next.js는 전체 서버리스 라우팅 로직을 제공하지 않으므로이 프로젝트가 격차를 메우는 데 필요한 이유. 장기적인 비전은 AWS부터 시작하여 다양한 구름으로 자조를 할 수 있도록하는 것입니다.
이 프로젝트는 다음 9 지원, 더 나은 개발 경험, 200 CloudFormation 리소스 제한 및 성능과 같은 핵심 문제를 해결하는 데 중점을 둔 서버리스 플러그인의 더 나은 버전입니다.
구성이 필요하지 않습니다. 응용 프로그램 요구에 따라 기본값을 확장 할 수 있습니다.
이 구성 요소의 사용자는 next dev (Next.js Development Tooling)을 사용할 수 있어야합니다. 우리가 알고 사랑하는 다음 모든 기능으로 패리티를 보장하는 것은 응용 프로그램을 배포하는 것이 구성 요소의 작업입니다. 우리는 Next.js의 전부 또는 대부분의 라우팅 및 서버 측로 로직을 모방하고 서버리스 환경을 위해 최적화하려고합니다. 아래에서 현재 지원되는 기능 목록을 찾을 수 있습니다.
단순화 된 아키텍처와 CloudFormation을 사용하지 않으면 응용 프로그램에 몇 페이지를 가질 수있는 페이지와 배포 시간이 매우 빠릅니다! 물론 Cloudfront 전파 시간을 제외하고.
우리는 다음.js 라우팅 로직을 모방하기 때문에 불행히도 우리는 항상 완전한 패리티가 아닙니다. 다음은 지원되는 모든 기능 또는 계획된 기능을 보여줍니다. 확인란이 체크되면 기능이 지원되었음을 의미합니다. 그렇지 않으면 아직 또는 현재 계획 또는 구현 단계에서 지원되지 않을 수 있습니다. 특정 세부 정보는 항목의 설명을 참조하십시오.
일부 기능은 최신 알파 버전에만있을 수 있습니다. 기능이 지원되는 것으로 표시되지만 latest 태그에서 작동하지 않으면 alpha 태그에있을 가능성이 높습니다. 가능하면 최신 알파 변경 사항을 테스트하고 문제가있는 경우 버그 보고서를 제출하도록 도와주십시오. 감사합니다!
원하는 기능이 있지만 아직 지원되지 않은 기능이 있습니까? 알려 주려면 새로운 문제를 열어주세요!
/_next/* Cloudfront에서 제공됩니다. getStaticProps 통해 OPT-In-STATIC Generation (SSG). getServerSideProps 통한 SSR (Server-Side Rendering)에서 선택합니다. getStaticPaths 통해 동적 소스에서 일련의 경로를 정적으로 생성합니다. _next/static/* 및 static/* 제외한 모든 경로는 리디렉션 할 수 있어야합니다. 해당 캐시 동작에는 Lambda 핸들러가 부착되어 있지 않기 때문입니다. 새로 has 하는 형식 (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching)은 아직 지원되지 않습니다. _next/static/* 및 static/* 제외한 모든 경로는 다시 작성할 수 있어야합니다. 해당 캐시 동작에는 Lambda 핸들러가 첨부되지 않기 때문입니다. 새로 has 하는 형식 (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching)은 아직 지원되지 않습니다. _next/static/* 및 static/* 제외한 사용자 정의 헤더를 가질 수 있어야합니다. 해당 캐시 동작에는 Lambda 처리기가 첨부되지 않기 때문입니다. 새로 has 하는 형식 (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching)은 아직 지원되지 않습니다. next-i18next 패키지를 사용하는 경우 기본 구성 파일을 자동으로 감지하고 복사합니다. 먼저 모든 코드가 ES2019로 변환되므로 배포 시스템에 Node.js 12+가 설치되어 있는지 확인하십시오. 다음 응용 프로그램을 Serverless.yml에 추가하십시오.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} " # it is recommended you pin the latest stable version of serverless-next.js serverless.yml 파일에 @sls-next/serverless-component 지정하면 package.json 파일에 @sls-next/serverless-component 추가하지 않으면 serverless.yml 파일의 버전 만 사용하지 않으며 NPM 자체에서 서버리스를 가져 오는 버전 만 사용하지 마십시오. 버전을 지정하지 않으면 latest 태그를 사용하는데, 여기서 최신 안정 버전 (예 : 알파 버전)을 나타냅니다.
package.json 사용하여 버전을 원하는 경우 로컬 설치를 가리킬 수도 있습니다.
이 경우 다음을 구성하십시오.
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "그런 다음 AWS 자격 증명을 환경 변수로 설정하십시오.
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhh간단히 배포 :
$ serverless새 서버리스 버전으로 인해 배포되는 문제가있는 경우 특정 버전 (예 : 2.72.2)으로 고정하십시오. #2320 (댓글) 참조
[Alpha- 버그가 될 수 있습니다] 당신은 또한 npx @sls-next/serverless-patched (또는 로컬로 설치 한 경우 serverless-patched )를 사용하여 배포 할 수 있습니다. 이는 serverless 리스/CLI : (1) internactive tertup (eg ci-untput)에 인쇄되는 @serverless/cli : (1) 메시지를 패치함으로써 몇 가지 문제를 수정하는 Serverless의 패치 버전입니다. (2) Silent Next.js 빌드 실패를 처리합니다.
또한 --debug 플래그를 추가하여 무대 뒤에서 일어나는 일에 대한 더 유용한 로그를 얻는 것이 좋습니다.
serverless deploy 실행하여 배포하려고하지 않으므로 serverless 만 사용하십시오.
대부분의 경우 CloudFront의 배포 도메인을 사용하여 응용 프로그램에 액세스하고 싶지 않습니다. 대신 사용자 정의 도메인 이름을 지정할 수 있습니다.
도메인 이름을 사용할 수 있지만 DNS 호스팅에는 AWS Route53을 사용해야합니다. 기존 도메인에서 DNS 레코드를 마이그레이션하려면 여기서 지침을 따르십시오. 사용자 정의 도메인 이름을 사용하기위한 요구 사항 :
mydomain.com )에 대한 호스팅 영역이 포함되어야합니다.Serverless Next.js 구성 요소는 SSL 인증서를 자동으로 생성하고 클라우드 프론트 배포를 가리키는 새 레코드를 작성합니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : " example.com " # sub-domain defaults to www
domainMinimumProtocolVersion : " TLSv1.2_2018 " # can be omitted, defaults to "TLSv1.2_2018" subdomain 을 구성 할 수도 있습니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] 자신의 클라우드 프론트 입력을 지정하려면 cloudfront 아래에 AWS-CloudFront 입력을 추가하십시오.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
# if you want to use an existing cloudfront distribution, provide it here
distributionId : XYZEXAMPLE # optional
# this is the default cache behaviour of the cloudfront distribution
# the origin-request edge lambda associated to this cache behaviour does the pages server side rendering
defaults :
forward :
headers :
[
CloudFront-Is-Desktop-Viewer,
CloudFront-Is-Mobile-Viewer,
CloudFront-Is-Tablet-Viewer
]
# this is the cache behaviour for next.js api pages
api :
minTTL : 10
maxTTL : 10
defaultTTL : 10
# you can set other cache behaviours like "defaults" above that can handle server side rendering
# but more specific for a subset of your next.js pages
/blog/* :
minTTL : 1000
maxTTL : 1000
defaultTTL : 1000
forward :
cookies : " all "
queryString : false
/about :
minTTL : 3000
maxTTL : 3000
defaultTTL : 3000
# you can add custom origins to the cloudfront distribution
origins :
- url : /static
pathPatterns :
/wp-content/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
- url : https://old-static.com
pathPatterns :
/old-static/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
- url : http://old-api.com
protocolPolicy : http-only
pathPatterns :
/old-api/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
aliases : ["foo.example.com", "bar.example.com"]
priceClass : " PriceClass_100 "
# You can add custom error responses
errorPages :
- code : 503
path : " /503.html "
minTTL : 5 # optional, minimum ttl the error is cached (default 10)
responseCode : 500 # optional, alters the response code
comment : " a comment " # optional, describes your distribution
webACLId : " arn:aws:wafv2:us-east-1:123456789012:global/webacl/ExampleWebACL/473e64fd-f30b-4765-81a0-62ad96dd167a " # ARN of WAF
restrictions :
geoRestriction :
restrictionType : " blacklist " # valid values are whitelist/blacklist/none. Set to "none" and omit items to disable restrictions
items : ["AA"] # ISO 3166 alpha-2 country codes
certificate :
cloudFrontDefaultCertificate : false # specify false and one of IAM/ACM certificates, or specify true and omit IAM/ACM inputs for default certificate
acmCertificateArn : " arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 "
iamCertificateId : " iam-certificate-id " # specify either ACM or IAM certificate, not both
sslSupportMethod : " sni-only " # can be omitted, defaults to "sni-only"
minimumProtocolVersion : " TLSv1.2_2019 " # can be omitted, defaults to "TLSv1.2_2019"
originAccessIdentityId : XYZEXAMPLE # optional
paths : ["/*"] # which paths should be invalidated on deploy, default matches everything, empty array skips invalidation completely
waitBeforeInvalidate : true # by default true, it waits for the CloudFront distribution to have completed before invalidating, to avoid possibly caching old page
tags : # Add any tags you want
tag1 : val1
tag2 : val2이것은 Cloudfront의 Edge 위치에서 다음.js 페이지를 캐싱하는 데 특히 유용합니다. 사용자 정의 캐시 구성이 포함 된 예제 응용 프로그램은이 참조를 참조하십시오. 사용자 정의 클라우드 프론트 입력을 사용하여 기존 클라우드 프론트 배포를 업데이트 할 수도 있습니다.
정적으로 렌더링 된 페이지 (예 : S3에 업로드 된 HTML 페이지)는 다음과 같은 캐시 제어 세트가 있습니다.
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxage 사용하면 Cloudfront가 31 일 동안 가장자리 위치의 페이지를 캐시 할 수 있습니다. max-age=0 must-revalidate 검증과 함께 브라우저가 정적 페이지를 캐시하지 않도록하십시오. 이를 통해 Cloudfront는 캐싱 TTL을 완전히 제어 할 수 있습니다. 배포마다 사용자가 새로운 콘텐츠를 얻을 수 있도록 무효화 /* 생성됩니다.
기본적으로 /public 또는 /static 폴더 아래의 공통 이미지 형식 ( gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico )은 1 년의 Cache-Control 정책 ( public, max-age=31536000, must-revalidate )을 가지고 있습니다. Cache-Control 헤더 value 과 publicDirectoryCache 사용하여 test 파일의 선수를 사용자 정의 할 수 있습니다.
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache :
value : public, max-age=604800
test : /.(gif|jpe?g|png|txt|xml)$/i value 유효한 Cache-Control 정책이어야하며 test 테스트하려는 파일 유형에 대한 유효한 regex 인이어야합니다. 브라우저가 공개 디렉토리에서 자산을 캐시하는 것을 원하지 않으면 다음을 비활성화 할 수 있습니다.
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : false기본적으로 Lambda@Edge 함수는 awslambdabasicexecutionRole을 사용하여 실행되므로 로그를 CloudWatch에만 업로드 할 수 있습니다. 예를 들어 DynamoDB 또는 기타 AWS 리소스에 대한 액세스와 같이이 이상의 권한이 필요한 경우 자신의 사용자 지정 정책 또는 역할 ARN이 필요합니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
policy : " arn:aws:iam::123456789012:policy/MyCustomPolicy " # serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
roleArn : " arn:aws:iam::123456789012:role/MyCustomLambdaRole "사용자 정의 정책 또는 역할에 CloudWatch 로그 권한을 추가하십시오. 최소 정책 json 예 :
{
"Version" : " 2012-10-17 " ,
"Statement" : [
{
"Effect" : " Allow " ,
"Resource" : " * " ,
"Action" : [
" logs:CreateLogGroup " ,
" logs:CreateLogStream " ,
" logs:PutLogEvents "
]
},
{
"Effect" : " Allow " ,
"Resource" : " arn:aws:s3:::s3-deployment-bucket-name/* " ,
"Action" : [ " s3:GetObject " , " s3:PutObject " ]
}
]
} 역할에는 lambda.amazonaws.com 및 edgelambda.amazonaws.com 과의 신뢰 관계가 포함되어야합니다.
참고 : bucketName 지정하고 policy 또는 roleArn 통해 해당 버킷에 액세스 할 수있는 권한을 제공하여 기본 및 API Lambdas가 정적 자원에 액세스 할 수 있습니다.
배포에 필요한 AWS 조치의 철저한 목록 :
"acm:DescribeCertificate", // only for custom domains
"acm:ListCertificates", // only for custom domains
"acm:RequestCertificate", // only for custom domains
"cloudfront:CreateCloudFrontOriginAccessIdentity",
"cloudfront:CreateDistribution",
"cloudfront:CreateInvalidation",
"cloudfront:GetDistribution",
"cloudfront:GetDistributionConfig",
"cloudfront:ListCloudFrontOriginAccessIdentities",
"cloudfront:ListDistributions",
"cloudfront:ListDistributionsByLambdaFunction",
"cloudfront:ListDistributionsByWebACLId",
"cloudfront:ListFieldLevelEncryptionConfigs",
"cloudfront:ListFieldLevelEncryptionProfiles",
"cloudfront:ListInvalidations",
"cloudfront:ListPublicKeys",
"cloudfront:ListStreamingDistributions",
"cloudfront:UpdateDistribution",
"cloudfront:TagResource", // for adding tags
"cloudfront:UntagResource", // for adding tags
"cloudfront:ListTagsForResource", // for adding tags
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreateServiceLinkedRole",
"iam:GetRole",
"iam:PutRolePolicy",
"iam:PassRole",
"lambda:CreateFunction",
"lambda:EnableReplication",
"lambda:DeleteFunction", // only for custom domains
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:PublishVersion",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:ListTags", // for tagging lambdas
"lambda:TagResource", // for tagging lambdas
"lambda:UntagResource", // for tagging lambdas
"route53:ChangeResourceRecordSets", // only for custom domains
"route53:ListHostedZonesByName",
"route53:ListResourceRecordSets", // only for custom domains
"s3:CreateBucket",
"s3:GetAccelerateConfiguration",
"s3:GetObject", // only if persisting state to S3 for CI/CD
"s3:ListBucket",
"s3:PutAccelerateConfiguration",
"s3:PutBucketPolicy",
"s3:PutObject",
"s3:PutBucketTagging", // for tagging buckets
"s3:GetBucketTagging", // for tagging buckets
"lambda:ListEventSourceMappings",
"lambda:CreateEventSourceMapping",
"iam:UpdateAssumeRolePolicy",
"iam:DeleteRolePolicy",
"sqs:CreateQueue", // SQS permissions only needed if you use Incremental Static Regeneration. Corresponding SQS.SendMessage permission needed in the Lambda role
"sqs:DeleteQueue",
"sqs:GetQueueAttributes",
"sqs:SetQueueAttributes"
기본 , API 및 이미지 (Next.js 이미지 최적화) 가장자리 람다에는 기본적으로 512MB의 메모리가 할당됩니다. 이 값은 memory 입력에 숫자를 할당하여 변경할 수 있습니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 기본값 , API 및 이미지 Lambdas의 값은 다음과 같은 객체에 memory 할당하여 별도로 정의 할 수 있습니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048node.js 런타임을 지정하기 위해 동일한 패턴을 따라갈 수 있습니다 (기본적으로 nodejs14.x).
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
runtime :
defaultLambda : " nodejs14.x "
apiLambda : " nodejs14.x "
imageLambda : " nodejs14.x " # Note that the sharp image library is built for Lambda Node.js 14.x, although it will likely work fine on other runtimes마찬가지로 기본적으로 시간 초과는 10 초입니다. 사용자 정의하려면 다음과 같이 할 수 있습니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15Lambda@Edge에 허용되는 최대 시간 초과는 30 초입니다. https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-requirements-limits.html을 참조하십시오
기본값 , API 및 이미지 람다에 대한 사용자 정의 이름을 설정할 수도 있습니다. 기본값이 아님이 Resource ID로 설정된 경우 기본값이 설정됩니다.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambda네 번째 재생 람다가 있으며, 이는 유사하게 구성 될 수 있으며 증분 정적 재생에 사용됩니다. 그러나 Lamda@Edge를 사용하지 않으며 예를 들어 시간 초과 설정이 더 길어질 수 있습니다.
Cloudfront에서 4 개의 캐시 동작이 생성됩니다.
처음 두 _next/* 와 static/* 요청을 S3으로 전달합니다.
세 번째는 세 가지 유형의 요청을 처리하는 람다 함수와 관련이 있습니다.
서버 측면 렌더링 페이지. getInitialProps 메소드를 정의하는 모든 페이지는이 레벨에서 렌더링되며 응답은 즉시 사용자에게 반환됩니다.
정적으로 최적화 된 페이지. HTML 옆에 미리 컴파일 된 페이지에 대한 요청은 S3로 전달됩니다.
공공 자원. /robots.txt , /favicon.ico , /manifest.json 등과 같은 루트 레벨 리소스에 대한 요청.
왜 2와 3.가 먼저 lambda@edge를 통과 해야하는 이유는 경로가 _next/* 또는 static/* 와 같은 패턴을 준수하지 않기 때문입니다. 또한 Cloudfront는 분포 당 25 개만 허용하기 때문에 경로 당 하나의 캐시 동작은 나쁜 생각입니다.
네 번째 캐시 동작은 다음 API가 api/* 요청합니다.
| 이름 | 유형 | 기본값 | 설명 |
|---|---|---|---|
| 배포 | boolean | true | False로 설정하면 앱을 공급자 (예 : AWS)에 배포하지 않습니다. |
| 도메인 | Array | null | 예를 들어 ['admin', 'portal.com'] |
| DomainRedirects | object | {} | 308 리디렉션을 사용하여 가장자리에 도메인 레벨 리디렉션을 추가합니다. 도메인 이름 -> 프로토콜로 대상 리디렉션 대상의 개체를 지정하십시오. 예를 들어, www.example.com: https://example.com . 자세한 내용은 여기를 참조하십시오. |
| 버킷 이름 | string | null | 정적 자산이 저장되는 맞춤형 버킷 이름. 기본적으로자가 생성됩니다. |
| 버킷 영역 | string | null | S3 버킷을 호스팅하려는 지역. 클라우드 프론트가 S3에 대한 요청을 프록시 할 때 대기 시간을 줄이기 위해 대부분의 최종 사용자와 지리적으로 더 가깝게 지리적으로 더 가깝게 지리적인지 확인하십시오. |
| 버킷 타그 | object | undefined | 버킷을 설정할 맞춤형 버킷 태그. 정의되지 않은 경우 구성 요소는 태그를 업데이트하지 않습니다. 빈 객체로 설정하면 모든 태그가 제거됩니다. |
| NextConfigdir | string | ./ | next.config.js 응용 프로그램이있는 디렉토리 .config.js 파일입니다. 이 입력은 serverless.yml 이 다음 앱과 동일한 디렉토리에 있지 않은 경우 유용합니다.참고 : nextConfigDir next.config.js 에 설정해야합니다 distDir |
| Nextstaticdir | string | ./ | static 또는 public 디렉토리가 nextConfigDir 의 직접 자녀가 아닌 경우 이것이 필요합니다. |
| 설명 | string | *lambda-type*@Edge for Next CloudFront distribution | 두 람다에 사용될 설명. "(API)"는 API Lambda 설명에 추가됩니다. |
| 정책 | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | 두 람다에 할당 될 ARN 또는 인라인 정책. |
| Rolearn | string|object | 널 | 역할의 ARN은 두 람다에 할당됩니다. |
| 실행 시간 | string|object | nodejs14.x | 값이 할당되면 기본값과 API Lambdas 모두 값에 정의 된 런타임이 할당됩니다. 객체에 할당 된 경우 기본값 및 API Lambdas의 값은 별도로 정의 할 수 있습니다. |
| 메모리 | number|object | 512 | 숫자를 할당하면 기본값과 API Lambdas에 해당 값에 대한 메모리가 할당됩니다. 객체에 할당 된 경우 기본값 및 API Lambdas의 값은 별도로 정의 할 수 있습니다. |
| 태그 | object | undefined | 람다에 할당 할 태그. 정의되지 않은 경우 구성 요소는 태그를 업데이트하지 않습니다. 빈 객체로 설정하면 모든 태그가 제거됩니다. |
| 시간 초과 | number|object | 10 | 위와 동일합니다 |
| 매니저 | string | index.handler | 값을 할당하면 기본 기능 핸들러를 대체하여 구성을 허용합니다. Lambda 폴더로의 경로에서 handler.js 복사합니다. 핸들러는 여전히 default-handler 에게 전화를 걸어야합니다. 그렇지 않으면 기능이 다음에 작동하지 않습니다. |
| 이름 | object | / | 모든 람다의 이름은 명시 적으로 정의 될 수 있습니다 |
| 짓다 | boolean|object | true | True가 앱을 빌드하고 배포 할 때, False가 앱을 구축했다고 가정하고 nextConfigDir 의 .next .serverless_nextjs 디렉토리를 사용하여 배포합니다. 객체가 전달되면 build 사용하면 스크립트가 호출되는 스크립트와 어떤 인수와 어떤 인수가 있는지 재정의 할 수 있습니다. |
| build.cmd | string | node_modules/.bin/next | 빌드 명령, 당신은 no-op 명령 (예 : true 또는 : unix 기반 시스템)을 전달할 수 있습니다. |
| build.args | Array|string | ['build'] | 빌드에 전달되는 주장 |
| build.cwd | string | ./ | 현재 작업 디렉토리를 대체하십시오 |
| build.enabled | boolean | true | 통과 build:false 이지만 구성 내에서 |
| build.env | object | {} | 스크립트에 추가 환경 변수를 추가하십시오 |
| build.postBuildCommands | Array | [] | 빌드 후 및 사전 배포를 실행하는 모든 명령. 예를 들어 .serverless_nextjs 디렉토리에서 모든 사용자 정의 코드를 실행할 수 있습니다. 예를 들어 Lambda에 추가 파일을 복사 할 수 있습니다. next-18n 의 예는 #767 (댓글)을 참조하십시오. serverless 명령을 실행하는 동안에 만 적용됩니다. |
| build.cleanupdotnext | boolean | true | 빌드 단계를 실행하기 전에 .next 디렉토리 정리 여부 |
| build.assetignorepatterns | string[] | [] | 글로벌 패턴은 _next/static, public, static 디렉토리에서 복사 할 파일을 발견 할 때 무시할 수 있습니다. |
| build.usev2handler | boolean | false | 실험은 일반적인 핸들러를 사용하기 시작하는 v2 핸들러를 사용하도록 이것을 true로 설정합니다. 참고 : 여기에는 separateApiLambda 및 disableOriginResponseHandler 기능이있어 함께 사용해서는 안됩니다. 또한 코드 크기 측면에서 아직 최적화되지는 않지만 여전히 수행해야합니다. 앞으로는 기본적 으로이 모드를 사용할 것입니다. |
| 클라우드 프론트 | object | {} | 입력은 AWS-CloudFront로 전달됩니다 |
| 증명서 | string | `` | 클라우드 프론트 배포에 사용할 특정 인증서 ARN. 사용하려는 와일드 카드 SSL 인증서가있는 경우 도움이됩니다. 이것은 현재 domain 입력과 함께 만 작동합니다. domain 입력을 사용할 필요없이 certificate 지정하는 방법에 대해서는 Custom CloudFront 구성을 확인하십시오 (도메인 입력으로 인해 모든 인증서가 재정의됩니다). |
| 도메인 유형 | string | "both" | "apex" - Apex Domain 만, www subdomain을 생성하지 마십시오. "www" - www 도메인 전용, Apex 하위 도메인을 생성하지 마십시오. "both" - 둘 중 하나가 제공되면 www 및 apex 도메인을 모두 만듭니다. |
| DomainMinimumProtocolversion | string | "TLSv1.2_2018" | "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" 중 하나 일 수 있습니다. 참조를 참조하십시오. |
| Public DirectoryCache | boolean|object | true | public / static 폴더 자산 캐싱 정책을 사용자 정의하십시오. value 및/또는 test 가있는 객체를 할당하면 캐싱 정책 및 캐시 된 파일 유형을 사용자 정의 할 수 있습니다. 허위 할당은 캐싱을 비활성화합니다 |
| useerErverlessTracetArget | boolean | false | 실험적 서버 트레이스 대상을 사용하여 다음 앱을 구축하십시오. 이것은 Vercel이 지금 사용하는 것과 동일한 빌드 대상입니다. 자세한 내용은이 RFC를 참조하십시오. 참고 : 이것을 사용하는 동안 NODE_ENV 변수를 production 에 설정해야 할 수도 있습니다. |
| 미니 핸들러 | boolean | false | 사전 구축 된 미니스트 핸들러를 사용하여 코드 크기를 줄입니다. 맞춤형 처리기를 미치지 않습니다. |
| enablehttpcompression | boolean | false | true 로 설정되면 SSR 및 API 요청의 lambda@edge 함수는 GZIP를 사용하여 응답을 압축합니다. Cloudfront가 상자 밖으로 응답을 압축하기 때문에이를 활성화 할 필요가 없습니다. |
| 입증 | object | undefined | 기본 인증과 함께 사용하기위한 인증 개체 (1.19.0-Alpha.3에서 제공). 현재 단일 사용자 이름/비밀번호 조합 만 지원하며 Lambda 핸들러에서 일반 텍스트로 인쇄됩니다. 또한 CloudFront 동작, 예를 들어 defaults , api/* 및 _next/data/_ 에 대한 Authorization 헤더를 전달해야합니다. 참고 : 이것은 개발/테스트 사이트와 같은 환경을 보호하는 간단한 수단으로, 생산 사용에는 권장되지 않습니다. |
| Authentication.username | string | undefined | 기본 인증을위한 사용자 이름. |
| 3acceleration을 활성화합니다 | boolean | true | S3 전송 가속도를 활성화할지 여부. 일부 AWS 지역이 지원하지 않으므로 비활성화하는 데 유용 할 수 있습니다. 참조를 참조하십시오. |
| remodllambdaversions | boolean | false | 배포 후 오래된 Lambda 버전 제거에 대한 기본 지원. true로 설정되면 배포 할 때마다 배포/복제되지 않은 모든 람다의 최대 ~ 50 개의 오래된 버전 (오래된부터 시작)이 자동으로 제거됩니다. 보다 복잡한 전략이 필요한 경우 이전 버전을 제거하기 위해 자신의 스크립트를 작성하는 것이 좋습니다. |
사용자 정의 입력은 다음과 같이 구성 할 수 있습니다.
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(실험) -이 구성을 속도로 높이고 서버리스 로직을 재사용하는 데 더 많은 작업이 필요합니다. 결과적으로 구성은 그에 따라 적응/변경 될 가능성이 높습니다.
문서는 여기에서 찾을 수 있습니다.
서버리스 환경을 위해 최적화하기 위해 Next.js 라우팅 로직을 거의 처음부터 에뮬레이션 할 때 (앞서 언급했듯이) 불완전하거나 누락 된 기능이있을 수 있습니다. 그러나 우리는 대부분의 기능을 다루었 고 안정성을 보장하기 위해 우수한 단위 및 엔드 투 엔드 테스트 커버리지를 추가했다고 생각합니다 (예 : 10 개 이상의 엔드 투 엔드 테스트 스위트). 몇몇 사람들은 이것을 사용하여 스타트 업, 개인 웹 사이트 등을 강화하고 있습니다.
클라우드 제공 업체 제한 사항도 적용됩니다. 예를 들어 AWS Lambda@Edge에서는 콜드 스타트, 코드 크기 제한, 1MB 응답 크기 제한 등이 있습니다. 물론 당신은 또한 현재 단일 플랫폼에 연결되어 있습니다 (Aws Lambda@Edge; 더 곧 출시 될 예정입니다!).
또한 가까운 시일 내에 더 나은 인프라로 코드로 인한 솔루션 (CDK, CDK Terraform, Pulumi 등)을 고려하여 배포 프로세스를 계속 개선하고 있습니다.
serverless.yml 이 serverless-components (Beta) 형식을 사용하는지 확인하십시오. 서버리스 구성 요소는 동일한 CLI를 통해 액세스 할 수 있지만 원래 서버리스 프레임 워크와 다릅니다.
✅
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other components하지 않다
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... 올바른 YAML이 provider , Resources 등을 선언하지 않는 방법에 유의하십시오.
배포하려면 serverless deploy 실행하지 마십시오. serverless 실행하면 serverless.yml 파일에 선언 된 구성 요소를 배포합니다.
서버리스 구성 요소에 대한 자세한 내용은 여기를 참조하십시오.
API 핸들러 및 기본 핸들러 패키지는 별도로 배포되지만 각각은 50MB의 ZIPPENT 또는 AWS 당 250MB의 제한이 있습니다. 여기와 여기를 참조하십시오. 디자인별로 현재 모든 페이지 경로에 대해 하나의 Lambda@Edge와 모든 API 경로에 대해 Lambda@Edge가 하나만 있습니다. 특히 API 경로, SSR 페이지 등이 많은 경우 코드 크기 문제로 이어질 수 있습니다.
코드 크기 문제가 발생하면 다음을 시도하십시오.
코드 크기 최적화 : SSR 페이지 및 API 경로에서 # 종속성을 줄이면 SSR 페이지가 적습니다 (예 : getInitialProps() 또는 getServerSideProps() 사용하지 않음).
minifyHandlers 입력을 사용하여 핸들러 코드 자체를 조정하십시오. 이렇게하면 처리기 크기가 ~ 500kb에서 ~ 200kb로 줄어 듭니다.
다음 웹 팩 구성을 다음 next.config.js 에 추가하여 Terser를 사용하여 서버 측 코드를 최소화/최소화하십시오. NEXT_MINIMIZE 환경 변수를 사용하여 SSR 코드를 최소화하기 위해 알려줍니다. 이로 인해 빌드 시간이 증가하고 코드를 조정하여 CloudWatch 오류를 디버그하기가 어려울 수 있습니다.
먼저 terser-webpack-plugin 의존성에 추가하십시오. 그런 다음 next.config.js :
const TerserPlugin = require ( "terser-webpack-plugin" ) ; webpack: ( config , { buildId , dev , isServer , defaultLoaders , webpack } ) => {
if ( isServer && ! dev && process . env . NEXT_MINIMIZE === "true" ) {
config . optimization = {
minimize : true ,
minimizer : [
new TerserPlugin ( {
parallel : true ,
cache : true ,
terserOptions : {
output : { comments : false } ,
mangle : true ,
compress : true
} ,
extractComments : false
} )
]
} ;
}
return config ;
} ;API 경로를 사용하지 않으면 정적 페이지 사전 페이지에서만 사용되는 모든 JS 파일은 번들에서 자동으로 제거됩니다. 그러나 API 경로를 사용하는 경우 미리보기 모드에 사용될 수 있으므로 제거하지 않습니다. API 경로를 사용하는 경우에도 미리보기 모드에서 사용되지 않은 이러한 JS 파일을 식별하고 제거하는 공식/비정규 적 방법은 없습니다. 그러나 필요한 경우 수동으로 제외하기 위해 새로운 입력을 추가 할 수 있습니다.
serverless.yml 에서 useServerlessTraceTarget 옵션을 사용하십시오. 다음.js는 각 페이지에 종속성을 번들로 묶지 않아야합니다 (대신 Lightweight Pages 생성). 그런 다음 serverless-next.js node_modules 에서 단일 종속성 세트를 참조합니다. 이는 Lambda@Edge 코드 크기 문제 (잠재적 솔루션에 대해서는 위의 참조) 또는 네트워크 업로드 속도가 느려지거나 큰 Lambda 패키지를 배포하려는 경우에 발생할 수 있습니다.
두 번째 경우, 사용 된 aws-sdk NPM 패키지의 기본 타임 아웃은 120 초입니다. 현재 이것은 구성 가능하지 않지만 가까운 시일 내에 더 긴 시간 초과를 지원할 수 있습니다 (서버리스/서버리스#937과 유사하게 서버리스 구성 요소가 아닌 서버리스 프레임 워크에만 적용됨).
기본적으로 Cloudfront는 Host 헤더를 S3 Origin 호스트 이름으로 설정합니다. Host 헤더를 원점으로 전달해야합니다. api/* 캐시 동작에 대한 전달은 아래 예제를 참조하십시오.
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] 사용자는 serverless-plugin 인 대신이 구성 요소를 사용하도록 권장됩니다. 이 구성 요소는 서버리스 플러그인에서 배운 수업을 사용하여 구축 및 설계되었습니다.
DynamODB와 상호 작용하는 예제 TODO 응용 프로그램에 대해서는 examples/dynamodb-crud 참조하십시오. 여기에서 전체 예 목록을 찾을 수 있습니다
불행히도, Serverless 구성 요소가 작동하는 방식 (적어도 베타 버전)으로 인해 배포 상태는 기본 serverless 명령 외부에서 동기화되어야합니다. 따라서 다음 솔루션을 시도해 볼 수 있습니다.
.serverless 디렉토리 아래의 파일입니다. 여러 단계에서는 잘 작동하지 않으므로 권장하지는 않지만..serverless 파일을 저장하고 여기에서 예제 (여러 serverless.yml 파일 사용) 또는 여기 (GitHub Actions 기반, 여러 serverless.yml 파일을 사용)를 참조하십시오.distributionId Cloudfront 입력을 사용하여 배포 할 기존 클라우드 프론트 배포를 지정할 수도 있습니다.앞으로 적절한 단계 관리를 구성 요소 자체에 통합하여이를 개선 할 것입니다.
이 프로젝트는 서버리스 구성 요소가 베타에있을 때 원래 저자가 시작했으며 불행히도 GA 구성 요소가 곧 출시되었습니다. 그러나 이것은 서버리스로 유지되지 않았기 때문에 여러 하위 경쟁자 가이 모노로로 수입되면서 점점 커졌습니다. 그리고 업그레이드하기가 어려워졌습니다.
GA 구성 요소로 업그레이드 할 계획이 있었지만 몇 가지 이유가 있습니다.
우리는 현재 적절한 IAC 솔루션 (예 : Terraform, CDK, Pulumi 등)과 같은 적절한 IAC 솔루션을 조사하고 복잡한 배치 로직을 유지하는 부담을 완화시켜 개발자 경험에 집중하고 다음에 다음과 같은 특징을 초래할 수 있습니다.
예! 메인 차단제는 Next.js 라우팅 로직이 Lambda@Edge/Cloudfront Logic과 크게 결합되어 있다는 것입니다. 그러나 대부분의 핵심 논리 ( @sls-next/core 패키지에)의 대부분을 일반화하여 다른 플랫폼에서 재사용 할 수 있도록, 단순히 랩핑 핸들러를 만들고 일부 플랫폼 별 클라이언트 (예 : 페이지를 검색하고, 정적 재생을 트리거하는 등)를 구현하고 배포기를 생성함으로써 재사용 할 수 있습니다. 당신이 관찰 한 경우, 현재 API 게이트웨이를 통해 Lambda 배포 작업에있는 새로운 패키지를 볼 수 있습니다 : https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. Azure 및 Google Cloud와 같은 다른 플랫폼이 곧 따라야합니다.
us-east-1 에 배치되었습니다. 다른 지역에 어떻게 배포 할 수 있습니까? Serverless Next.js는 영역이 없습니다. Design에 의해 serverless-next.js 응용 프로그램은 전세계에 모든 Cloudfront Edge 위치에 배포됩니다. Lambda는 us-east-1 에만 배치되어있을 수 있지만 무대 뒤에서 다른 모든 지역에 복제됩니다.
추가 인수 및 환경 변수를 빌드에 전달하는 고급 build 설정은 아래 샘플을 참조하십시오.
# serverless.yml
myDatabase :
component : MY_DATABASE_COMPONENT
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
build :
args : ["build", "custom/path/to/pages"]
env :
DATABASE_URL : ${myDatabase.databaseUrl} ${env.VARIABLE}-blah 와 같은 환경 변수를 다른 문자열과 연결하려고하면 Serverless Framework는 ${env.VARIABLE} 으로 만 해결하는 것으로 보입니다.
서버리스 구성 요소의 버그 인 것 같습니다. 최신 GA 버전을 사용하지 않았기 때문에 수정되었을 수 있습니다 (불행히도 여전히 구성 요소 베타에 있습니다). 지금은 해결 방법이 다음과 같습니다.
serverless.yml 변수를 먼저 설정 한 다음 연결하십시오. stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com Host 헤더 및 domainType: both 전달과 함께 새로운 domainRedirects 입력을 사용하여 요청을 올바른 도메인으로 리디렉션 할 수 있습니다. www.example.com 요청을 https://example.com 으로 리디렉션하는 아래 구성 예제를 참조하십시오.
next-app :
component : " ../../serverless-components/nextjs-component "
inputs :
cloudfront :
defaults :
forward :
headers : [Host]
domain : ["example.com"]
domainType : " both "
domainRedirects :
www.example.com : https://example.com 이 모든 것은 Lambda@Edge Origin 요청 처리기 내에서 발생합니다. 캐시 동작에는 lambda@edge handler가 첨부되지 않기 때문에 _next/static/* 또는 /static/* 에서 요청을 리디렉션 할 수 없습니다.
그렇지 않으면 여기에 설명 된 S3 버킷을 사용하여 수동 해결 방법을 사용할 수도 있습니다. 요약하면, 새로운 S3 버킷을 만들어 정적 웹 사이트 호스팅으로 설정하여 지원되는 하위 도메인 유형 (예 : "www.example.com"또는 "example.com")에 대한 요청을 리디렉션합니다. HTTPS 리디렉션을 지원하려면 S3 리디렉션 버킷을 사용하여 원점으로 클라우드 프론트 분포를 설정해야합니다. 마지막으로, 새로 생성 된 클라우드 프론트 분포를 별칭 대상으로 사용하여 Route 53에서 "A"레코드를 작성해야합니다.
build.env 내 앱에 나타나지 않습니다. 앱이 정의 된 환경 변수에 액세스하려면 여기에 설명 된대로 next.config.js 를 통해 노출해야합니다.
이런 식으로 serverless.yml
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "다음 .config.js는 다음과 같아야합니다.
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; 다음과 같은 오류가 표시 될 수 있습니다.
502 ERROR
The request could not be satisfied.
The Lambda function returned invalid JSON: The JSON output is not parsable. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
응답의 크기가 너무 큰 경우 일반적으로 발생합니다. Lambda@Edge는 현재 Origin Request Handler에 의해 반환 된 1MB의 제한이 있습니다. 참조 : https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-generating-http-responses-in-requests.html#lambda-generating-http-respones-errors. 불행히도, 응답이 더 작아지는 것 외에는 해결 방법이 없을 수 있습니다.
CloudFront 구성을 통해 Accept-Language 헤더를 전달하십시오. 사용자가 이해하고/또는 선호하는 언어를 결정할 수 없습니다. 기본적으로 전달되지만 자신의 구성으로 재정의하면 다시 추가해야합니다.
타사 라이브러리를 사용하고있는 경우 (현재 next-i18next 만) 기본 경로를 사용하는 경우 일부 파일을 Lambda 디렉토리에 복사해야 할 수도 있습니다. 이 구성 요소는 기본 파일을 감지하여 복사하려고합니다. 그러나 사용자 정의 구성이있는 경우 파일 등을 복사하려면 자신의 postBuildCommands 작성해야 할 수도 있습니다.
자세한 정보 및 경고는 readme를 참조하십시오.
여기에서 새로운 문제를 열 수 있습니다. 문제를 게시하는 경우 유용한 팁을 얻으려면 먼저 디버깅 Wiki를 따르고 문제를 재현 할 수있는 많은 정보를 포함 시키십시오.
보안 취약성을보고하는 경우 보안 정책을 대신 팔로우하십시오.
Please note that there is only one core maintainer right now (@dphang), and a handful of community contributors, who all contribute to this library in their free time. So we hope you understand that our response is best-effort and may take several days, or more. So we hope you could at least help debug the issue or provide as much context. In case an issue hasn't been looked at for a long time (> a few weeks) or it seems like a major issue, feel free to mention a maintainer and we will try to prioritize it.
We would love if you can help contribute, whether it's coding, triaging or debugging issues, helping with documentation, or financial support! Please see the contributing guide.
This project exists thanks to all the people who contribute. [기여하다].
Made with contributors-img.
Become a financial contributor and help us sustain our community. [기여하다]
Support this project with your organization. 귀하의 로고는 귀하의 웹 사이트 링크와 함께 여기에 표시됩니다. [기여하다]
