serverless next.js
v3.7.0
ゼロ構成next.js 10/11 AWSラムダ@エッジ用のサーバーレスコンポーネント完全機能のパリティを目指しています。
現在サポートされている機能のリストについては、機能を確認してください。
ショ和 このREADMEは、masterブランチの最新の変更を反映しています。 NPMでlatest（安定）またはalphaリリースに公開されている場合とまだ公開されていない場合があります。リリースに移動し、使用している正しい@sls-next/serverless-componentバージョンを見つけて、より正確な情報を得るためにそのリリースのREADMEを開きます。このREADMEに機能がリストされているが機能していない場合は、まずNPMの最新のalphaリリースにアップグレードしてみてください。
これは現在、GAの前にプロジェクトが開始されたため、サーバーレスコンポーネントベータ（GAバージョンではない）を使用しています。現在、展開が将来どのように機能するかを作り直し、CDK、CDK用CDKなどのより良いIACソリューションを調査しており、年末までに更新を発表します。
Next.js 8.0以降、サーバーレスモードが導入され、このようなプロジェクトが異なるクラウドプロバイダーへの展開に使用できる新しい低レベルAPIを提供します。ただし、next.jsは完全なサーバーレスルーティングロジックを提供していないため、ギャップを埋めるためにこのプロジェクトが必要な理由です。長期的なビジョンは、AWSから始めて、さまざまなクラウドで自己ホストできるようにすることです。
このプロジェクトは、次の9つのサポート、開発エクスペリエンス、200のクラウド形成リソースの制限、パフォーマンスなどのコアの問題に対処することに焦点を当てたサーバーレスプラグインのより良いバージョンです。
構成はほとんど必要ありません。アプリケーションのニーズに基づいてデフォルトを拡張できます。
このコンポーネントのユーザーは、next.js開発ツール、 next devを使用できる必要があります。アプリケーションを展開することは、私たちが知っている、愛する次のすべての機能のすべてと同等を確保するためのコンポーネントの仕事です。 next.jsのルーティングおよびサーバー側のロジックのすべてまたはほとんどをエミュレートし、サーバーレス環境に合わせて最適化しようとします。以下に、現在サポートされている機能のリストを見つけることができます。
単純化されたアーキテクチャとCloudFormationを使用していない場合、アプリケーションにいくつのページを持つことができるか、さらに展開時間が非常に速くなります。もちろん、クラウドフロントの伝播時間を除きます。
Next.jsルーティングロジックをエミュレートするため、残念ながら私たちは常に完全な平等ではありません。以下は、すべてのサポートされている機能または計画機能を示しています。チェックボックスがチェックされている場合、機能がサポートされていることを意味します。それ以外の場合は、まだサポートされていないか、現在計画または実装段階ではサポートされていない可能性があります。特定の詳細については、アイテムの説明を参照してください。
一部の機能は、最新のAlphaバージョンのみにある可能性があることに注意してください。機能がサポートされているがlatestタグでは動作しないとリストされている場合、おそらくalphaタグにある可能性があります。可能であれば、問題が見つかった場合は、最新のアルファの変更をテストし、バグレポートを提出してください。ありがとう！
あなたが望むがまだサポートされていない機能はありますか？新しい問題を開いてお知らせください！
/_next/* CloudFrontから提供されます。 getStaticPropsを介して静的生成（SSG）にオプトインします。 getServerSidePropsを介してサーバー側のレンダリング（SSR）にオプトインします。 getStaticPathsを介して動的ソースから一連のルートを静的に生成します。 _next/static/*およびstatic/*を除いてリダイレクトできる必要があります。これらのキャッシュの動作には、それらにラムダハンドラーが付いていないためです。新しいものhas一致する形式（https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching）はまだサポートされていないことに注意してください。 _next/static/*およびstatic/*を除いて書き直すことができるはずです。これらのキャッシュの動作には、ラムダハンドラーが付着していないためです。新しいものhas一致する形式（https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching）はまだサポートされていないことに注意してください。 _next/static/*およびstatic/*を除くカスタムヘッダーを持つことができるはずです。これらのキャッシュの動作には、ラムダハンドラーが付着していないためです。新しいもの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指定している場合、 @sls-next/serverless-componentをPackage.jsonファイルに追加しないでくださいserverless.ymlファイルのバージョンのみが使用されます。バージョンを指定しない場合、ここで最新の安定したバージョンを指す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新しいサーバーレスバージョンのために展開の問題がある場合は、特定のバージョンEG 2.72.2に固定してみてください。 ＃2320（コメント）を参照してください
[Alpha-be buggy] npx @sls-next/serverless-patched @serverless/cliまたはローカルにインストールした場合はserverless serverless-patched ）を使用して展開することもできます。 （2）silent next.jsの故障を処理します。
また、舞台裏で起こっていることのより便利なログを取得するために、 --debugフラグを追加することもお勧めします。
serverless deployを実行して展開しようとしないでください、 serverlessのみを使用します
ほとんどの場合、CloudFrontの分布ドメインを使用してアプリケーションにアクセスしたくありません。代わりに、カスタムドメイン名を指定できます。
任意のドメイン名を使用できますが、DNSホスティングにAWS Route53を使用する必要があります。既存のドメインからDNSレコードを移行するには、こちらの指示に従ってください。カスタムドメイン名を使用するための要件：
mydomain.comなど）を含める必要があります。ServerLess Next.jsコンポーネントは、SSL証明書を自動的に生成し、CloudFront Distributionを指す新しいレコードを作成します。
# 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 Locationsで次の.jsページをキャッシュするのに特に役立ちます。カスタムキャッシュ構成を備えたアプリケーションの例については、これを参照してください。また、カスタムクラウドフロント入力を使用して既存のクラウドフロント分布を更新することもできます。
静的にレンダリングされたページ（つまり、s3にアップロードされるhtmlページ）には、次のキャッシュコントロールセットがあります。
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxageを使用すると、CloudFrontは31日間、Edgeの場所でページをキャッシュできます。 max-age=0 must-revalidateて、ブラウザが静的ページをキャッシュしないようにします。これにより、CloudFrontがキャッシュTTLを完全に制御できるようになります。すべての展開では、ユーザーが新しいコンテンツを確実に取得できるように、無効化/*が作成されます。
デフォルトでは、一般的な画像形式（ gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico ）の下の/publicまたは/staticフォルダーには、1年間のCache-Controlポリシーが適用されます（ public, max-age=31536000, must-revalidate ）。 publicDirectoryCacheを使用して、 Cache-Controlヘッダーvalueと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デフォルトでは、cloudwatchにログをアップロードすることのみを可能にするawslambdabasicexecutionroleを使用して、lambda@edge関数を使用して実行されます。これ以上のアクセスが必要な場合、たとえば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 Image Optimizationの場合）Edge Lambdasには、デフォルトで512MBのメモリが割り当てられます。この値は、 memory入力に数値を割り当てることで変更できます
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024デフォルト、 API 、および画像ラムダの値は、次のようなオブジェクトに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 、および画像ラムダのカスタム名を設定することもできます。デフォルトではない場合は、AWS -LAMBDAサーバーレスコンポーネントによってリソースIDに設定されます。
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambda4番目の再生ラムダがあります。これは、同様に構成でき、増分静的再生に使用されます。ただし、Lamda@Edgeを使用せず、たとえば、より長いタイムアウト設定を持つことができます。
CloudFrontで4つのキャッシュ動作が作成されます。
最初の2つの_next/*およびstatic/*要求をS3に転送します。
3番目は、3種類のリクエストの処理を担当するLambda関数に関連付けられています。
サーバーサイドレンダリングページ。 getInitialPropsメソッドを定義するページはこのレベルでレンダリングされ、応答はすぐにユーザーに返されます。
静的に最適化されたページ。 HTMLの隣で事前にコンパイルされたページへのリクエストは、S3に転送されます。
公共リソース。 /robots.txtなど/favicon.icoルートレベルリソースへのリクエスト。これら/manifest.json S3に転送されます。
2。および3。lambda@edgeを最初に通過する必要がある理由は、ルートが_next/*やstatic/*などのパターンに適合しないためです。また、クラウドフロントは分布ごとに25しか許可されていないため、ルートごとに1つのキャッシュ動作は悪い考えです。
4番目のキャッシュ動作は、次のAPI要求api/*処理します。
| 名前 | タイプ | デフォルト値 | 説明 |
|---|---|---|---|
| 展開する | boolean | true | falseに設定すると、アプリをプロバイダーに展開しません（AWSなど）。 |
| ドメイン | Array | null | たとえば['admin', 'portal.com'] |
| domainredirects | object | {} | 308リダイレクトを使用して、ドメインレベルのリダイレクトをエッジに追加します。ドメイン名のオブジェクト - >プロトコルで宛先をリダイレクトします。たとえば、 www.example.com: https://example.com 。詳細については、こちらをご覧ください。 |
| BucketName | string | null | 静的資産が保存されるカスタムバケット名。デフォルトでは自動生成されます。 |
| バケット | string | null | S3バケツをホストしたい地域。 CloudFrontがS3へのリクエストをプロキシをプロキシしている場合、これはエンドユーザーの大部分に地理的に近いことを確認してください。 |
| バケット | object | undefined | バケツに設定するカスタムバケットタグ。未定義の場合、コンポーネントはタグを更新しません。空のオブジェクトに設定すると、すべてのタグが削除されます。 |
| NextConfigdir | string | ./ | next.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またはインラインポリシー。 |
| ロールアーン | string|object | ヌル | 両方のラムダに割り当てられる役割のARN。 |
| ランタイム | string|object | nodejs14.x | 値が割り当てられた場合、デフォルトとAPIラムダの両方に、値で定義されたランタイムが割り当てられます。オブジェクトに割り当てられた場合、デフォルトとAPIラムダの値を個別に定義できます |
| メモリ | number|object | 512 | 番号が割り当てられた場合、デフォルトとAPIラムダの両方にその値のメモリが割り当てられます。オブジェクトに割り当てられた場合、デフォルトとAPIラムダの値を個別に定義できます |
| タグ | object | undefined | ラムダに割り当てるタグ。未定義の場合、コンポーネントはタグを更新しません。空のオブジェクトに設定すると、すべてのタグが削除されます。 |
| タイムアウト | number|object | 10 | 同上 |
| ハンドラ | string | index.handler | 値が割り当てられたら、デフォルトの関数ハンドラーをオーバーライドして構成を可能にします。ラムダフォルダへのルート内のhandler.jsをコピーします。あなたのハンドラーは後もdefault-handlerに電話する必要があります。そうしないと、next.jsで機能が機能しません。 |
| 名前 | object | / | すべてのラムダの名前は明示的に定義できます |
| 建てる | boolean|object | true | Trueがアプリをビルドして展開すると、Falseがアプリがビルドされていると仮定し、 nextConfigDirの.next .serverless_nextjsディレクトリを使用して展開します。オブジェクトが渡された場合、 buildすると、どのスクリプトが呼び出され、どのような引数を使用してオーバーライドできます。 |
| build.cmd | string | node_modules/.bin/next | コマンドをビルドすると、not-opコマンド（eg trueまたは: unixベースのシステム）を渡すことができます。 |
| build.args | Array|string | ['build'] | ビルドに渡す議論 |
| build.cwd | string | ./ | 現在の作業ディレクトリをオーバーライドします |
| build.enabled | boolean | true | BUILDの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 | 実験的に、これをgenericizedハンドラーの使用を開始するV2ハンドラーを使用するためにこれをtrueに設定します。注：これには、 separateApiLambdaの機能性があり、 disableOriginResponseHandlerことで、一緒に使用する必要はありません。また、コードサイズの点ではまだ完全に最適化されていませんが、それでもパフォーマンスを発揮する必要があります。将来的には、デフォルトでこのモードを使用する可能性があります。 |
| クラウドフロント | object | {} | AWS-CloudFrontに渡される入力 |
| Certificatearn | string | `` | クラウドフロント配布に使用する特定の証明書ARN。使用したいワイルドカードSSL証明書がある場合は役に立ちます。これは現在、 domain入力と並行してのみ機能します。 domain入力を使用する必要なくcertificateを指定する方法については、カスタムクラウドフロント構成を確認してください（ドメイン入力により証明書をオーバーライドすることに注意してください）。 |
| domaintype | string | "both" | "apex" - 頂点ドメインのみ、WWWサブドメインを作成しないでください。 "www" - wwwドメインのみ、頂点サブドメインを作成しないでください。 "both" - どちらかが提供されたときにwwwドメインと頂点ドメインの両方を作成します。 |
| domainminimumprotocolversion | string | "TLSv1.2_2018" | "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016"の1つにすることができます。参照を参照してください。 |
| publicDirectoryCache | boolean|object | true | public / staticフォルダーアセットキャッシングポリシーをカスタマイズします。 valueおよび/またはtestでオブジェクトを割り当てると、キャッシュポリシーとキャッシュされるファイルの種類をカスタマイズできます。 falseの割り当てはキャッシュを無効にします |
| useServerlessTraceTarget | boolean | false | Experimental-Server-Less-Trace Targetを使用して、次のアプリを構築します。これは、Vercelが現在使用しているのと同じビルドターゲットです。詳細については、このRFCを参照してください。注：これを使用している間、 NODE_ENV変数をproductionに設定する必要がある場合があります。 |
| MinifyHandlers | boolean | false | 事前に構築された削除ハンドラーを使用して、コードサイズを削減します。カスタムハンドラーを縮小しません。 |
| enabableHttpcompression | 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地域ではサポートしていないため、無効にすると便利です。参照を参照してください。 |
| remodyoldlambdaversions | boolean | false | 確実に展開した後、古いLambdaバージョンを削除するための基本的なサポート。 Trueに設定すると、展開するたびに、展開/複製されていないすべてのラムダの最大50個の古いバージョン（最も古いものから始まる）が自動的に削除されます。より複雑な戦略が必要な場合は、古いバージョンを削除するために独自のスクリプトを記述することをお勧めします。 |
カスタム入力は次のように構成できます。
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket（実験） - このコンストラクトをスピードアップし、サーバーレスロジックの一部を再利用するために必要な作業が必要です。その結果、コンストラクトはそれに応じて適応/変更する可能性があります。
ドキュメントはこちらをご覧ください。
next.jsルーティングロジックをゼロからほぼゼロからエミュレートしているため、サーバーレス環境に合わせて最適化するため、不完全または欠落している機能がある場合があります（前述のように）。ただし、機能の大部分をカバーしており、安定性を確保するために優れたユニットとエンドツーエンドのテストカバレッジを追加したと感じています（たとえば、10以上のエンドツーエンドテストスイート）。何人かの人々がこれを使用して、スタートアップ、個人的なウェブサイトなどを強化しています。
クラウドプロバイダーの制限も適用されます。たとえば、AWS Lambda@Edgeでは、コールドスタート、コードサイズの制限、1 MBの応答サイズ制限などがあります。もちろん、今のところ単一のプラットフォームにも結び付けられています（AWS Lambda@Edge;詳細が近づいています！）。
また、近い将来にコードとしてのより良いコードソリューション（CDK、CDK Terraform、Pulumiなど）を検討することにより、展開プロセスを改善し続けています。
serverless.ymlがserverless-components （ベータ）形式を使用していることを確認してください。サーバーレスコンポーネントは、両方とも同じ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ハンドラーとデフォルトのハンドラーパッケージは個別に展開されますが、それぞれが50 MBのzippidまたは250 MBのAWSごとに圧縮されていない制限があります - こちらとこちらを参照してください。設計上、現在、すべてのページルートに1つのLambda@Edgeと、すべてのAPIルートに1つのLambda@Edgeしかありません。これにより、特に多くのAPIルート、SSRページなどがある場合は、コードサイズの問題につながる可能性があります。
コードサイズの問題に遭遇している場合は、次のことを試してください。
コードサイズの最適化：SSRページとAPIルートで＃依存関係を削減し、SSRページが少なくなります（つまり、 getInitialProps()またはgetServerSideProps()を使用しません）。
minifyHandlers入力を使用して、ハンドラーコード自体をマイニーします。これにより、ハンドラーのサイズが〜500 kbから〜200 kbに削減されます。
次のWebpack構成を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オプションを使用します。これにより、next.jsは各ページに依存関係をバンドルすることなく（代わりに軽量ページを作成します）、 serverless-next.js node_modulesの単一の依存関係セットを参照します。 これは、Lambda@Edgeコードサイズの問題（潜在的なソリューションについては上記を参照してください。関連するGithubの問題）があるか、ネットワークのアップロード速度が遅い場合、および/または大規模なLambdaパッケージの展開を試みている可能性があります。
2番目のケースでは、使用されている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と対話するexamples/dynamodb-crudについては、例を参照してください。ここで例の完全なリストを見つけることができます
残念ながら、サーバーレスコンポーネントの仕組み（少なくともベータ版）のため、展開状態はメインserverlessコマンドの外側で同期する必要があります。したがって、次のソリューションを試すことができます。
.serverlessディレクトリの下のファイルです。ただし、複数の段階ではうまく機能しないため、これは推奨されません。.serverlessファイルを保存したり、ここで例を参照したり（Multiple serverless.ymlファイルを使用します）、またはここ（GitHub Actions Based、Multiple serverless.ymlファイルを使用します）を参照してください。distributionId CloudFront入力を使用して、既存のクラウドフロント配信を指定することもできます。将来的には、適切なステージ管理をコンポーネント自体に統合することにより、これを改善することを検討します。
このプロジェクトは、サーバーレスコンポーネントがベータ版になったときに元の著者によって開始され、残念ながらGAコンポーネントはその後まもなくリリースされました。しかし、これはより大きく成長し、サーバーレスによって維持されていなかったため、このモノレポにいくつかのサブコンポーネントがインポートされました。そして、アップグレードが難しくなりました。
GAコンポーネントにアップグレードする計画がありましたが、いくつかの理由で保留されました。
現在、これに対処し、複雑な展開ロジックを維持する負担を軽減するために、適切なIACソリューション（Terraform、CDK、PulumiなどのCDKなど）を検討しています。
はい！メインブロッカーは、next.jsルーティングロジックがlambda@edge/cloudfrontロジックと高度に結合されていたことでした。ただし、ほとんどのコアロジック（ @sls-next/coreパッケージに）を一般化したため、他のプラットフォームで再利用できるように、ラッピングハンドラーを作成し、プラットフォーム固有のクライアントを実装し（例：ページを取得し、静的再生をトリガーするなど）、展開者を作成します。 Observantの場合、API Gateway：https：//github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambdaを介してLambdaの展開のために現在作業中の新しいパッケージに新しいパッケージに気付くでしょう。 AzureやGoogle Cloudのような他のプラットフォームは、すぐに続くことを願っています。
us-east-1に展開されています。どうすれば別の地域に展開できますか？ ServerLess Next.jsは地域レスです。設計上、 serverless-next.jsアプリケーションは、世界中にすべてのCloudFront Edgeの場所に展開されます。ラムダは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のような別の文字列で環境変数を連結しようとすると、サーバーレスフレームワークは${env.VARIABLE}のみに解決するようです。
サーバーレスコンポーネントのバグのようです - それは、修正された可能性のある最新のGAバージョンを使用していないためかもしれません（これは残念ながら、まだコンポーネントベータ版にあります）。今のところ、回避策は次のとおりです。
serverless.yml変数を設定し、次に連結してください。 stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com 新しいdomainRedirects入力を使用して、 HostヘッダーとdomainType: both転送して、正しいドメインにリクエストをリダイレクトできます。 https://example.comへのリダイレクトwww.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リクエストハンドラー内で発生します。これにより、 _next/static/*または/static/*でリクエストをリダイレクトできないことに注意してください。これらのキャッシュの動作には、lambda@edgeハンドラーが付属していないためです。
それ以外の場合は、ここで概説するS3バケットを使用して、手動回避策を使用することもできます。要約すると、新しいS3バケツを作成し、サポートされているサブドメインタイプにリクエストをリダイレクトするための静的Webサイトホスティングでセットアップする必要があります（ex。 "www.example.com"または "example.com"）。 HTTPSリダイレクトをサポートできるようにするには、S3リダイレクトバケットを使用してクラウドフロント分布を起源としてセットアップする必要があります。最後に、新しく作成されたCloudFront Distributionをエイリアスターゲットとして、ルート53に「A」レコードを作成する必要があります。
build.envに設定された私の環境変数は、私のアプリに表示されませんアプリが定義された環境変数にアクセスできるようにするには、ここで概説しているように、 next.config.jsを介してそれらを公開する必要があります。
serverless.ymlがこのように与えられます
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "あなたのnext.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によって返される1 MBの制限があります。参照：https：//docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-generating-http-responses-in-requests.htmbda-generating-http-responses-errors。残念ながら、応答が小さくなるようにする以外に回避策はないかもしれません。
CloudFront構成を介して、 Accept-Languageヘッダーを転送してください。これは、ユーザーが理解している、および/または好む言語を決定することができないことを確認してください。デフォルトでは転送されますが、独自の構成をオーバーライドする場合は、追加する必要があります。
サードパーティライブラリ（今のところnext-i18nextのみ）を使用してデフォルトパスを使用している場合、一部のファイルをLambdaディレクトリにコピーする必要がある場合があります。このコンポーネントは、デフォルトファイルを検出し、それらをコピーしようとします。ただし、カスタム構成がある場合は、ファイルなどをコピーするために独自のpostBuildCommandsを作成する必要がある場合があります。
詳細と警告については、READMEを参照してください。
ここで新しい問題を開くことができます。問題を投稿する場合は、最初にWikiのデバッグに従って、いくつかの有用なヒントについては、問題を再現するために多くの情報を含めるようにしてください。
セキュリティの脆弱性を報告している場合は、代わりにセキュリティポリシーに従ってください。
現在、コアメンテナーは1つ（@dphang）と、自由時間にこの図書館に貢献しているコミュニティの貢献者が少数していることに注意してください。 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. Your logo will show up here with a link to your website. [貢献する]
