Aws-lambda-dotnet: .NET Core 3.1(LTS)이 출시되었습니다.

LTS이며 지원됩니다. Lambda에 .NET Core 3.1을 준비하고 배포하는 데 약간의 시간이 걸립니다.

LTS이며 지원됩니다. .NET Core 3.1이 Lambda용으로 준비되고 배포되는 데 시간이 걸립니다.

제가 도울 수 있는 일이 있으면 알려주세요.

콜드 스타트 ​​시간에 대한 속도 향상이 있습니까?

.NET Core 3.1에는 AOT 컴파일과 같은 몇 가지 기능이 있습니다.

• 게시 준비 완료
• PublishTrimmed

@normj 는 업데이트를 위해 이 문제를 구독해야 합니까, 아니면 진행을 위해 따라야 하는 다른 .NET Core 3.1 문제가 있습니까?

이 문제를 사용하여 업데이트를 추적할 수 있습니다. 불행히도 나는 그것이 나올 때까지 많은 상태 업데이트를 제공할 수 없을 것입니다.

콜드 스타트 ​​시간에 대한 속도 향상이 있습니까?

.NET Core 3.1에는 AOT 컴파일과 같은 몇 가지 기능이 있습니다.

• 게시 준비 완료
• PublishTrimmed

댓글에 대한 대답이 예인 경우 로컬 환경에서 '컴파일된 람다'를 실행하고 테스트할 수 있습니까? 나는 그것을 위해 열심히 리눅스 환경을 설정할 것입니다 :)

업데이트가 있습니까?

@rati-dzidziguri

@normj 에서 위와 같이

이 문제를 사용하여 업데이트를 추적할 수 있습니다. 불행히도 나는 그것이 나올 때까지 많은 상태 업데이트를 제공할 수 없을 것입니다.

@beeradmoore
제 질문은 ETA에 관한 것이었습니다. 이에 따라 준비할 수 있으므로 이에 대한 ETA를 아는 것이 도움이 될 것입니다.

@rati-dzidziguri Amazon은 릴리스와 관련하여 ETA를 거의 공개하지 않습니다.

@rati-dzidziguri ETA를 원하는 것을 이해하고 감사하며 그에 따라 계획을 세울 수 있습니다. 실제로 우리가 지킬 수 있다는 100% 확신이 없는 약속을 하지 않기 위해 정말 열심히 노력하기 때문에 일반적으로 ETA를 제공하지 않는 이유입니다. 나는 당신에게 ETA를 제공하는 것을 싫어하고 당신이 그것을 기반으로 로드맵을 만들면 우리는 당신이 당신의 모든 계획을 혼란에 빠뜨릴 것으로 예상했던 ETA를 그리워합니다.

지금은 .NET Core 3.1 기능이 정말로 필요한 경우 여기 에 설명된 Lambda 사용자 지정 런타임으로 .NET Core 3.1을 사용하는 것이 좋습니다(.NET Core 3.0에서 .NET Core 3.1로의 변경 참조 제외). 그런 다음 기본 .NET Core 3.1 지원이 제공되면 Lambda 함수에서 몇 가지 설정을 변경하는 매우 간단한 마이그레이션이 수행됩니다.

@normj 'LambdaEntry' 클래스와 함께 사용자 정의 런타임 기능을 사용할 수 없다고 결정한 이유 중 하나는 구현 방식의 '모놀리식 아키텍처' 측면 때문입니다. 모든 API 요청은 단 하나의 항목 람다를 통해 이루어지며 ASP .net 프로젝트의 컨트롤러에 '배포'되는 것은 사용자 정의 런타임 구조가 의도한 것입니다. 이는 확실히 편리하지만 내가 원하는 경우에 대한 구조적 단점을 포함합니다. 모든 명령/쿼리 요청이 각각 람다가 되기를 원합니다. 그 이후로 일부 기능을 분할하고 내가 원할 때마다 코드를 관리할 수 있는 배포 패키지 관리에 대한 확장성을 얻을 수 있습니다.
이것이 'runtime : .netcore 3.1' 구성의 템플릿에 작성된 SAM을 사용하여 '단일 목적 람다' 번들을 구성할 수 있도록 공식 런타임이 지원되기를 기다리는 이유입니다.

잘못된 부분이 있으면 조언 부탁드립니다 :)

Lambda 부트스트래퍼와 사용자 지정 런타임 기능을 사용하여 하나의 코드 기반에서 여러 람다 함수를 확실히 달성할 수 있습니다.

"모놀리스"가 아닌 하나의 애플리케이션에서 배포되는 16개의 람다 제품군이 있습니다.

이는 블로그 게시물의 샘플 코드에 표시된 하드 코딩된 일대일 매핑 대신 _handler 환경 변수를 사용하여 런타임에 사용할 메서드를 선택하여 수행됩니다.

나는 그것을 시작할 때 어떤 행동이 "될"지를 알려주는 스위치를 수신하는 콘솔 앱이라고 생각합니다.

@martincostello
친절한 제안 감사합니다! 나는 당신의 경우가 어떻게 생겼는지 알아낼 수 있습니다. 런타임의 첫 번째 단계에서 기능인지 확인할 수 있도록 Main 또는 Startup 클래스에 스위치 논리를 배치했을 수 있습니다. 물론 '유일한' 문제도 해결할 수 있습니다. 아주 영리한 접근 :)

하지만 여전히 한 가지(많지는 않더라도) 고려해야 할 사항이 있습니다. 특히 팀으로 일하는 것을 상상할 때 그렇습니다. 사용자 정의 런타임을 사용하고 시작 시 '기능적 ID'를 결정하면 SAM의 가능성이 제거됩니다. 쉬운 예로 람다를 배포하는 동안 API 게이트웨이를 정의할 수 없으므로 수동으로 생성해야 합니다.
aws tutorial이 설명한 것처럼 부트스트랩 스크립트를 사용하여 SAM과 같은 구성을 만들 수 있기 때문에 여기에서 과장하고 있다는 것을 압니다. 그러나 그것은 리눅스 스크립트를 사용하기 때문에 우리를 완전히 만족시키지 못할 것입니다.
(1) 처음 온 사람들에게는 당혹스러울 수 있고 때로는 학습 곡선이 될 것입니다.
(2) 말 그대로 문서가 아니라 스크립트이기 때문에 서버리스 템플릿의 표현력의 이점을 버립니다.

서버리스 템플릿은 서버가 어떻게 생겼는지, 어떻게 작동하는지에 대한 준 문서로 작동하며, 이는 개발 팀 내에서 뿐만 아니라 통찰력 있는 비기술자에게도 공유될 것입니다. 그리고 SAM은 가까운 장래에 응용 프로그램에 대한 추상적인 표현이 완전히 다른 언어와 플랫폼을 사용하는 다른 팀에서 재사용할 수 있게 될 것이라는 잘 정의된 개념입니다. 이러한 측면은 여전히 ​​'서버리스 템플릿' 기능을 계속 사용하도록 동기를 부여합니다.

12월 25일, 1월 1일이 출시되기 전에 몇 가지 좋은 날짜가 떠오릅니다. ;)

모두 즐거운 휴일 보내세요. 크리스마스에 .NET Core 3.1 Lambda 런타임을 모두 제공하고 싶지만 2020년은 .NET 및 AWS에 대한 흥미진진한 해가 될 것입니다.

모두 즐거운 휴일 보내세요. 크리스마스에 .NET Core 3.1 Lambda 런타임을 모두 제공하고 싶지만 2020년은 .NET 및 AWS에 대한 흥미진진한 해가 될 것입니다.

걱정마세요, 명절 잘 보내세요! 2020년에 우리에게 무엇을 줄지 기대해주세요! :)

.NetCore3.1에서 람다 기본 지원을 기다리고 있습니다.

람다 함수에는 디스크 크기 제한이 있습니다. 250메가이고 사용자 지정 런타임을 사용할 때 앱과 함께 모든 asp.net 핵심 어셈블리를 보내야 한다고 생각합니다. AWS가 내 zip 패키지의 압축을 풀 때 해당 한도에 도달했습니다. 내 앱에서 사용하는 공간을 줄이기 위해 정리를 해야 했습니다. 기본 지원이 나오면 .core의 어셈블리로 앱을 패키징할 필요가 없습니다.

언제 출시될지 예상할 수 있습니까?

기본 지원이 있을 때까지 .Net core 3.1로 업그레이드하기를 기다리고 있습니다.

언제 출시될지 예상할 수 있습니까?

기본 지원이 있을 때까지 .Net core 3.1로 업그레이드하기를 기다리고 있습니다.

돌아가서 답장을 읽으면 normj에서 견적을 제공하지 않는다는 것을 읽을 수 있습니다.

돌아가서 답장을 읽으면 normj에서 견적을 제공하지 않는다는 것을 읽을 수 있습니다.

음, 일반적으로 -- 그렇습니다. 그러나 충분한 수의 사람들이 피치 포크를 가지고 나타나면 불안을 진정시키기 위해 출시 날짜에 대한 힌트가 제공될 것입니다.

AWS에서 2.1 네이티브 이미지를 준비하는 데 오랜 시간을 보냈을 때가 기억납니다. 그들은 향후 버전을 보다 쉽고 빠르게 구축할 수 있도록 프로세스를 재설계했다는 취지로 말했습니다. NetCore 3.1을 입력하고 거의 두 달이 지난 후에도 여전히 사용할 수 없습니다.

Azure에서 1일 차에 이 3.1 이미지를 사용할 수 있다는 것을 알고 있습니다. 미국 정부가 JEDI용 클라우드 공급자로 Azure를 선택하는 이유를 이해하기 시작했습니다.

이해 관계자로부터 AWS를 백업으로 남겨두고 기본 공급자로 Azure를 목표로 삼기 시작하라는 승인을 받았습니다. 이와 같은 어리석은 지연으로, 나는 우리가 유일한 사람이 아니라고 확신합니다.

AWS에서 2.1 네이티브 이미지를 준비하는 데 오랜 시간을 보냈을 때가 기억납니다. 그들은 향후 버전을 보다 쉽고 빠르게 구축할 수 있도록 프로세스를 재설계했다는 취지로 말했습니다. NetCore 3.1을 입력하고 거의 두 달이 지난 후에도 여전히 사용할 수 없습니다.

Azure에서 1일 차에 이 3.1 이미지를 사용할 수 있다는 것을 알고 있습니다. 미국 정부가 JEDI용 클라우드 공급자로 Azure를 선택하는 이유를 이해하기 시작했습니다.

이해 관계자로부터 AWS를 백업으로 남겨두고 기본 공급자로 Azure를 목표로 삼기 시작하라는 승인을 받았습니다. 이와 같은 어리석은 지연으로, 나는 우리가 유일한 사람이 아니라고 확신합니다.

동의합니다. 내 조직은 사용자 정의 런타임을 허용하지 않으며 우리는 2.1에 갇혀 있습니다. 공간 연산과 함께 EF & Postgres의 경우 너무 고통스럽습니다. 우리는 이것이 완료되기를 기다리고 있습니다. 아직 이루어지지 않은 것이 아쉽습니다.

AWS에서 2.1 네이티브 이미지를 준비하는 데 오랜 시간을 보냈을 때가 기억납니다. 그들은 향후 버전을 보다 쉽고 빠르게 구축할 수 있도록 프로세스를 재설계했다는 취지로 말했습니다. NetCore 3.1을 입력하고 거의 두 달이 지난 후에도 여전히 사용할 수 없습니다.

Azure에서 1일 차에 이 3.1 이미지를 사용할 수 있다는 것을 알고 있습니다. 미국 정부가 JEDI용 클라우드 공급자로 Azure를 선택하는 이유를 이해하기 시작했습니다.

이해 관계자로부터 AWS를 백업으로 남겨두고 기본 공급자로 Azure를 목표로 삼기 시작하라는 승인을 받았습니다. 이와 같은 어리석은 지연으로, 나는 우리가 유일한 사람이 아니라고 확신합니다.

JEDI는 .NET Core를 사용하여 정부가 Azure를 선택한 이유를 가정합니까?

안녕하세요 여러분,

저는 Lambda에서 .NET Core 3.1에 대한 지원을 가져오기 위해 적극적으로 노력하고 있습니다. Microsoft에서 런타임을 빌드하는 방법에 많은 작업을 수행했기 때문에 시간이 걸립니다. 네이티브 런타임을 제공하기 위해 이러한 변경 사항을 통합하는 작업을 하고 있습니다.

@assyadh 감사합니다! 나는 지연이 "어리석은" 것이라고 믿지 않습니다. 사실, 나는 오히려 제대로 작동하는 버전을 기다리고 싶습니다. AWS Lambda가 .NET Core를 지원한다는 점이 마음에 들고 약속한 대로 계속 지원해 주셔서 감사합니다.

나는 충동을 이해하지 못한다. 현재 LTS 환경이 없는 것은 아닙니다.

분명히 우리는 새 장난감을 사용하고 싶지만 AWS의 .NET 팀에는 고정된 양의 리소스만 있고 한 번에 모든 작업을 수행할 수 없습니다.

게다가, 나는 서비스 기간이 끝날 것을 두려워하여 모든 기능의 런타임을 서두르고 업데이트해야 할 필요성을 갈망하지 않습니다.

@Kralizek 에게 좋은 @JamesQMurphy가 말했듯이 우리는 또한 릴리스가 견고한 것을 선호합니다.

@assyadh님의 작업을 기대합니다.

"나는 충동을 이해하지 못한다."

.NET Core 2.1 람다 함수에서 공유 .NET Core 3.1을 사용할 수 없습니다. 사실 .NET Core 2.1 람다 함수에서 공유 .NET Core 2.2 코드를 사용할 수도 없습니다. 그래서 최근에 마지 못해 다운그레이드해야 했습니다. .NET Core 2.1에 공유 구성 요소를 추가하여 기능에서 지원되도록 합니다.

공유 구성 요소를 netstandard20에서 컴파일할 수 있습니까? 그런 다음 netcore2&3에서 공유할 수 있습니다.

이 스레드는 .NET 3.1에만 해당되지만 이 정확한 대화는 .NET 5가 도착할 때 다시 재생될 것이라고 확신합니다(또는 다음 LTS가 될 경우 6).

불가능한 경우(예: 코드 ZIP 파일이 너무 큼, 회사 정책) 일부 특정 예가 인용되었지만 _일반적으로_ 앞으로 "최신 및 최고의" .NET Core를 사용하려는 경우 다음을 사용하여 수행할 수 있습니다. 약간의 리팩토링 및 사용자 지정 런타임 지원 패키지.

현재 우리는 최신 릴리스가 LTS 릴리스인 _또한 발생_하는 지점에 와 있습니다. 이로 인해 Amazon에서 "최대한 빨리" 제공해야 할 필요성이 이전보다 훨씬 더 "긴급"하게 보입니다. 2.2 또는 3.0 지원 기능이 내장되어 있습니다.

궁극적으로 Lambda에서 사용할 수 있는 새로운 기능과 PaaS 솔루션에 투입해야 하는 개발 노력 사이에는 절충점이 있습니다.

.NET Core 3.1은 릴리스된 후 2-3주 동안 Microsoft의 Azure App Service에서도 사용할 수 없었습니다.

일반적으로 최대한 빨리 "최첨단"에 서고 싶다면 단기적으로 사용자 지정 런타임 지원을 사용하는 데 약간의 투자를 하면 잠재적으로 자신의 시간 척도에 따라 Lambda에서 .NET Core의 모든 향후 버전을 실행할 수 있습니다. 물론 여기에서 다른 것들 사이에서 트레이드 오프는 더 큰 패키지, 약간 더 많은 코드 및 자체 패치를 수행해야 할 필요성입니다.

모든 것에는 균형과 절충점이 있으며 기본 제공 지원의 경우 소프트웨어에는 시간이 걸리기 때문에 현실적으로 항상 가용성 지연이 있습니다.

.NET의 주요 릴리스가 11월에 진행됨에 따라 크리스마스/공휴일 기간은 Lambda 팀의 시간과 사용 가능한 용량 측면에서 이러한 기능을 기본적으로 제공하는 데 걸리는 시간에 항상 영향을 미칠 것입니다.

제 생각을 덧붙이자면. 이번 릴리스가 얼마나 중요한지 잘 알고 있으며 알려주셔서 감사합니다. 나는 그 피드백을 사용하여 긴급성을 우리 편으로 밀어붙입니다. @martincostello가 언급했듯이 .NET Core 3.1이

저는 과거에 2.1에 대해 언급한 사람이었습니다. 저는 우리가 배치한 자동화가 향후 릴리스의 속도를 높일 수 있기를 희망했습니다. @assyadh 가

따라서 .NET Core 3.1이 @assyadh , 나와 다른 많은 사람들이 완료하는 데 가장 우선 순위가

확인하기 위해 최종 릴리스를 기다리지 않고 Microsoft가 시험판을 릴리스하면 통합 작업이 시작됩니까? 그것은 아마도 크리스마스의 영향을 줄이고 테스트가 필요하기 때문에 최종 릴리스가 나오면 더 빨리 전달될 수 있도록 할 것입니다.

나는 그 피드백을 사용하여 긴급성을 우리 편으로 밀어 넣습니다.

@normj님 감사합니다. 여기 내 $0.02가 있습니다. 여러분의 전도에도 도움이 되기를 바랍니다.

@martincostello가 언급했듯이 .NET Core 3.1이

@mungojam이 언급했듯이 .NET Core 3.1은 릴리스 전 한 달이 넘는 기간 동안 10월 15일부터 미리 보기 형식 으로 제공되었습니다. 또한 기본적으로 3.0의 버그 수정 릴리스입니다. 도구는 모르지만 탐색 작업은 9월 23일 에 릴리스되었으며 일년 내내 미리 보기로

.NET Core 3.1은 릴리스된 후 2-3주 동안 Microsoft의 Azure App Service에서도 사용할 수 없었습니다.

.NET Core 3.1은 미리 보기 1이 릴리스된 지 이틀 후인 10월 17 일에 Azure Functions에서 사용할 수 있습니다.

"최첨단"이든, 사용자 지정 런타임 옵션이든, 어떤 회사에서든 3.1이 즉시 필요하다고 말할 수 있지만 이것은 실제로 AWS가 우리 .NET을 얼마나 진지하게 지원하기를 원하는지에 대한 더 큰 그림의 일부입니다. 고객. Norm의 팀이 아니라 전반적으로 AWS가 우선 순위를 지정했다면 이보다 앞서서 Azure와 경쟁할 수 있었을 것이라고 생각해야 합니다.

개인적으로 저는 클라우드 오퍼링 중에서 기업 도그마보다 장점을 기반으로 선택할 수 있는 옵션을 갖는 것을 매우 중요하게 생각하며 AWS가 .NET 지원을 개선하는 데 다음 단계를 수행하는 것을 보고 싶습니다.

@normj , @assyadh 및 귀하의 노력에 대해 이 작업을 수행하는 다른 모든

AWS의 .NET 팀이 3.0 미리 보기 릴리스와 함께 .NET 3.1 LTS를 준비하는 여정을 아주 잘 시작했을 수 있습니다. 문제는 AWS가 막 뒤에서 어떤 작업을 하고 있는지에 대해 입을 다물고 있다는 것입니다. 이러한 투명성의 부족은 추측을 낳습니다. 비록 잠정적이며 날짜가 변경될 수 있는 등의 상황이더라도 일종의 로드맵이 있다면 나쁘지 않을 것이라고 생각합니다.

문제는 AWS 팀이 어떤 종류의 ETA도 내놓고 싶어하지 않기 때문에 개발자가 어둠 속에 있다는 것입니다. @normj 는 그 누구도 또는 어떤 회사도 이러한 ETA를 기반으로 미래 계획을 세우는 것을 원하지 않기 때문이라고 말합니다. ETA는 어디까지나 추정치일 뿐, 어떤 회사도 다른 회사의 추정치를 바탕으로 진지한 계획을 세워서는 안 되며, 설령 그렇다고 해도 ETA를 놓쳤다고 AWS를 탓하거나 화를 낼 수 없다는 것이 일반적인 인식 아닌가요?

ETA도 특정 날짜가 아닙니다. 한 달이 될 수 있습니다. 쿼터. 그리고 우리는 모든 ETA에 대해 OK를 해야 하며 놓친 경우에도 OK입니다.

바라보는
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
AWS는 해당 런타임 버전의 수명 종료 직후 런타임을 더 이상 사용하지 않는 것 같습니다.

.NET Core LTS 버전은 3년 동안 지원되기 때문에 이미
".NET Core 3.1 람다를 사용할 수 있는 시간 보내기".
따라서 사람들이 람다에서 .NET Core 3.1을 얻기 위해 참을성이 없다는 것을 이해합니다.
BTW, 나는 또한 락 솔리드 릴리스를 선호하고 뭔가 서두를 것입니다.

다음 달이나 두 달 안에 사용할 수 있다고 가정하지만 AWS의 약속,
매우 보수적일지라도 팀이 운영을 계획하는 데 도움이 될 수 있습니다.

또 다른 점은 이 OSS 시대에 .NET 커뮤니티가 도움을 줄 수 있습니까? 우리는 결국 github에 대해 이야기하고 있습니다.
이 "내장" 런타임이 폐쇄형 코드입니까?

또한 배포 프로세스에 ReadyToRun 및 기타 AOT 컴파일 기능을 수행하는 스위치가 있으므로 콜드 스타트 ​​시간이 심각하게 단축되는 것은 KILLER 기능이 될 것입니다.
그러면 .NET Core가 AWS Lambda, IMO에서 매우 매력적입니다.

@normj 와 팀:
AWS에서 .NET Core를 훌륭하게 만들어 주셔서 감사합니다.

제 생각을 덧붙이자면. 이번 릴리스가 얼마나 중요한지 잘 알고 있으며 알려주셔서 감사합니다. 나는 그 피드백을 사용하여 긴급성을 우리 편으로 밀어붙입니다.

이 게시물을 사용하여 긴급 상황을 푸시하십시오. 이를 염두에두고 여기 내 두 페니가 있습니다.

확인하기 위해 최종 릴리스를 기다리지 않고 Microsoft가 시험판을 릴리스하면 통합 작업이 시작됩니까?

질문: 이 질문에 대한 정직한 답변을 얻을 수 있습니까?

답은 자명한 것 같습니다. .NET의 우선 순위는 "엔터프라이즈 수준"이 아니라 "취미 수준"인 것처럼 느껴집니다.

1) Net Core 전체가 오픈 소스로 만들어졌으며 2) 실제 출시와 동시에 "시작"할 수 있는 얼리 어답터 프로그램이 있다는 것을 어디선가 들었습니다. (자세한 내용은 Google을 참조하십시오.)

나는 여기서 웃기고 있지만 사실은 .NET을 따르는 모든 사람들이 이것을 알고 있다는 것입니다.

솔직히 말해서, 릴리스의 2.1 지연 이후, 당시의 변경 사항으로 인해 이번에(3.1)에 실제 릴리스로부터 2주 이내에 새 프레임워크에 대한 지원을 받을 수 있기를 희망했습니다. 내 말은 출시 후 몇 시간 이내에 이상적이지만 2주 이내에 최종 수정/광택을 위한 공간을 제공하는 것이 적절하다고 생각합니다.

그러나 여기에서 우리는 거의 두 달 동안 "취미 수준"으로 느껴집니다.

@rati-dzidziguri ETA를 원하는 것을 이해하고 감사하며 그에 따라 계획을 세울 수 있습니다. 실제로 우리가 지킬 수 있다는 100% 확신이 없는 약속을 하지 않기 위해 정말 열심히 노력하기 때문에 일반적으로 ETA를 제공하지 않는 이유입니다.

@abukres가 다음과 같이 우아하게 말하는 것처럼 이것은 "취미 수준의" 생각입니다.

문제는 AWS 팀이 어떤 종류의 ETA도 내놓고 싶어하지 않기 때문에 개발자가 어둠 속에 있다는 것입니다. @normj 는 그 누구도 또는 어떤 회사도 이러한 ETA를 기반으로 미래 계획을 세우는 것을 원하지 않기 때문이라고 말합니다. ETA는 어디까지나 추정치일 뿐, 어떤 회사도 다른 회사의 추정치를 바탕으로 진지한 계획을 세워서는 안 되며, 설령 그렇다고 해도 ETA를 놓쳤다고 AWS를 탓하거나 화를 낼 수 없다는 것이 일반적인 인식 아닌가요?

ETA도 특정 날짜가 아닙니다. 한 달이 될 수 있습니다. 쿼터. 그리고 우리는 모든 ETA에 대해 OK를 해야 하며 놓친 경우에도 OK입니다.

AWS가 Azure에 대한 JEDI 계약을 상실했다는 사실은 .NET이 "엔터프라이즈 수준"의 노력이며 그렇게 취급되어야 함을 표면적으로 증명하기 때문에 내부적으로 일부 우선 순위 회의를 시작하기에 충분했어야 한다고 생각합니다. 결정에 대해 "고소"하려고 리소스를 낭비하는 대신 이러한 리소스를 내부적으로 사용하여 .NET 커뮤니티에 사랑을 전하세요. 이 시간을 .NET의 우선 순위를 다시 지정하여 다음 .NET 릴리스에서 AWS가 상위에 오르도록 하고 처음부터 실행할 준비가 되었음을 자명합니다.

@normj , @martincostello 및 AWS의 나머지 일벌들은 SOLID .NET 제품을 제공하기 위해 정말 열심히 일하고 있습니다. 이러한 (커뮤니티) 불만 사항은 그 자체가 아니라 문화/정치적 문제임 을 이해해 주십시오. .NET과 관련하여 귀하에게 주어진 우선 순위 권한을 지시합니다. 이 게시물을 사용하여 "엔터프라이즈 수준" 지원을 달성할 수 있습니다.

저는 주로 이것을 AWS가 빛날 기회를 놓친 것으로 봅니다. 새로운 LTS 릴리스를 따르는 것이 높은 우선 순위가 될 것이라고 상상해보십시오. 그것은 얼마나 강력한 성명서가 될 것입니다.

이와 같은 일로 인해 개발자/건축가는 다음 프로젝트에 사용할 클라우드를 결정해야 할 때 비기술적 의사 결정자에 대한 논쟁을 잃게 됩니다. Azure와 AWS가 대부분 동일한 비용과 기능을 제공하는 요즘에는 정책과 인식에 대한 결정이 더 많이 내려집니다. "공식 릴리스 후 X주/달이 지났고 AWS가 아직 준비되지 않았습니다"라고 말할 때 가져올 것이 없습니다.

다시 @VagyokC4가 말했듯이 이것은 실제 작업을 수행하는 직원에 대한 개인적인 것이 아니라 상위 AWS 관리에 대한 모닝콜입니다.

.NET Core 3.1 Lambda를 수행하는 모든 사람은 IL 트리밍 활성화를 고려할 수 있습니다. 대부분의 경우 zip 파일의 크기를 줄일 것입니다.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

.NET 코어 람다 3.1은 RuntimeAPI를 사용하여 빌드되었습니까?
공개적으로, github에서?
그렇지 않다면 왜 안됩니까?

내가 원하는 것은 .... 발렌타인 데이는 람다 .net 코어 3.1 지원입니다.

내가 원하는 것은 .... 발렌타인 데이는 람다 .net 코어 3.1 지원입니다.

정확히 혀를 굴리지는 않지만 겸손합니다.

나는 크리스마스 발렌타인 데이에 많은 것을 원하지 않습니다.
나에게 필요한 것은 단 한 가지
나는 선물에 관심이 없다
AWS 트리 아래
난 그냥 내 자신을 원해
당신이 알 수 있었던 것보다 더
내 소원을 이루어줘 oh
내가 발렌타인 데이에 원하는 것은 .NET Core 3.1 지원뿐입니다 ...

:이를 드러내고 웃다:

Microsoft는 주요 변경 사항을 도입하지 않을 예정인 미리 보기 주기가 끝날 때 Go Live 라이선스를 포함합니다. 그 시점까지 그들은 다가오는 릴리스에 대한 프로덕션 지원을 제공합니다. Go Live 라이선스로 출시할 때까지 기다렸다가 도구 작업을 시작하는 것이 좋습니다. .NET Core 3.1에서는 11/14에 릴리스된 Preview 3에 제공되었습니다. 이 경우 RTM이 3주 후인 12월 3일에도 없었지만 RTM이 출시되고 고객이 기대를 쌓기 시작할 때 기능을 출시하는 데 더 가까워질 것입니다.

내 $0.02

내가 원하는 것은 .... 발렌타인 데이는 람다 .net 코어 3.1 지원입니다.

정확히 혀를 굴리지는 않지만 겸손합니다.

~크리스마스~발렌타인데이에 많은 걸 바라지 않아
나에게 필요한 것은 단 한 가지
나는 선물에 관심이 없다
AWS 트리 아래
난 그냥 내 자신을 원해
당신이 알 수 있었던 것보다 더
내 소원을 이루어줘 oh
내가 발렌타인 데이에 원하는 것은 .NET Core 3.1 지원뿐입니다 ...

😁

+1 :)

Lambda용 .NET Core 3.1 런타임에 대한 업데이트가 있습니까?

우리는 새로운 프로젝트를 시작하고 있으며 대부분의 서버리스에 Lamba를 사용하는 것에 크게 기대고 있었습니다.

<Rant>
AWS Lambda Runtime 지원 정책이 이와 같은 기능이 30일 이상 요구되는 경우 약 30일이라는 기간에 대해 매우 엄격하다는 점은 실망스럽습니다. 그러면 마법처럼 언젠가 AWS가 이 기능을 배포하고 다른 모든 사람들은 .NET Core 3.1로 전환하기 위해 서둘러야 할 것입니다. 이로 인해 프로덕션 환경에 무언가를 수정, 테스트 및 배포하는 데 한 달 이상이 걸리는 경우가 많기 때문에 대부분의 조직이 좋지 않은 상황에 놓이게 됩니다. 나는 개인적으로 이 정책에 대해 약간의 충격을 받았습니다. 한 번(자원 제약 및 기타 더 높은 우선 순위 때문에) 내가 있던 회사는 이 시간을 놓쳤습니다. 3개월이 지나야 Lambda를 .NET Core 2.1로 업그레이드할 수 있었습니다. CloudFront를 사용하여 특정 람다를 배포하려고 하면 나쁜 일이 발생하여(CF 로그가 쓰레기이므로 누가 알겠습니까?) 롤백해야 했습니다. 롤백할 런타임이 없다는 점을 제외하고. 따라서 배포가 LOCKED 입니다. 우리는 즉시 티켓을 열었습니다. 24시간 후에 "전체 스택을 삭제하고 다시 시작하십시오"라는 첫 번째 응답을 받았습니다. "삭제" 작업으로 DynamoDb 테이블을 가져갔다는 점을 고려하면 완전히 무식한 응답입니다. 우리는 2주 반 동안 롤백에 갇혀 있었습니다. 결국 우리는 컨테이너 기술을 이해하고 롤백을 도운 지원 엔지니어를 확보한 다음 CloudFormation이 성공할 때까지 대기했습니다. 첫 번째 시도에는 아무런 변화가 없었습니다. 이것이 내가 CF를 싫어하는 이유입니다. 사용하기에 너무 변덕스럽기 때문입니다.
</Rant>

TL;DR; AWS Lambda Runtime Support 정책은 작업하기 불편하고 뜨거운 물에 빠질 수 있습니다.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead 실망스러운 경험을 해서 죄송합니다. 하지만 .NET Core 3.1이 Lambda에서 출시되는 시기에 관계없이 .NET Core 2.1 런타임은 Microsoft 지원 주기에 따라 최소 2021년 8월 21일까지 Lambda에서 지원됩니다. 2.1 기능을 3.1로 변환하기 위해 서두를 필요가 없습니다. 귀하의 이전 경험은 .NET Core 2.0이 Lambda에 적용되는 유일한 비 LTS 버전이었기 때문에 Lambda에 대한 변칙이었다고 가정합니다. 이는 .NET Core 1.0의 몇 가지 주요 문제로 인해 수행되었습니다.

예, .NET Core 2.0에서 .NET Core 2.1로의 마이그레이션이었습니다. 욕해서 죄송합니다. 30일은 우리에게 다소 빡빡합니다. 전체 길이를 보면 람다는 상당한 유지 관리 및 추가 QA 없이 잠재적으로 실행될 수 있습니다.

한편, 이것은 서버리스의 Azure 측에서 발생합니다.
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

그동안 AWS 팀에서 작업 중입니다. 비꼬는 댓글은 도움이 안됨
그들을. 이 문제가 준비되면 업데이트할 것입니다.

2020년 2월 11일 화요일 18:22, Rati Dzidziguri [email protected]
썼다:

한편, 이것은 서버리스의 Azure 측에서 발생합니다.

https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYYY3PNVWWK3TUL52HS4DFVEXG43NVMVBW
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

제 요점은 비꼬는 말을 하려는 것이 아니라 MS가 최근에 3.1에 대한 GA 가용성을 발표했음을 지적하는 것이었습니다. 따라서 AWS가 곧 3.1 지원에 대한 작업을 마무리하는 것을 보기를 바랍니다.
.

한편, 이것은 서버리스의 Azure 측에서 발생합니다.
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

MS 언어를 고려할 때 Azure가 AWS를 이기는 것은 놀라운 일이 아닙니다.

이 스레드를 자세히 관찰하면서 C# Lambda를 업그레이드할 수 있기를 기대합니다.

닷넷 코어 3.1.0이 출시되었습니다. 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

2020-01-23에 Azure에서 사용할 수 있었습니다.
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

우리는 Azure에 비해 한 달이 더 짧습니다.

BTW, 모든 .NET 핵심 개발은 github에서 공개적으로 수행됩니다.
따라서 "MS 언어"인 것은 큰 효과가 없습니다.
아니면 dotnet을 사용하는 AWS 클라이언트가 Azure:P에서 더 낫다고 제안하십니까?

어쨌든 AWS에서 듣는 모든 사람에게:
Lambda에서 3.1을 기다리고 있습니다. 우리에게 중요합니다.

BTW, 모든 .NET 핵심 개발은 github에서 공개적으로 수행됩니다.
따라서 "MS 언어"인 것은 큰 효과가 없습니다.
아니면 dotnet을 사용하는 AWS 클라이언트가 Azure:P에서 더 낫다고 제안하십니까?

내 말은, 마이크로소프트의 클라우드 플랫폼이 그들 자신의 언어의 새로운 기능을 지원하지 않는 것은 약간 당혹스러울 것입니다. 솔직히 한 달 반이 조금 넘게 걸렸다는 사실에 조금 놀랐습니다! 내부 커뮤니케이션이 조금 더 많았더라면 두 가지를 동시에 출시할 수 있었을 것입니다.

AWS가 .Net 지원, 특히 CloudWatch + ILogging 및 SSM 매개변수 구성 연결과 같은 서비스에 연결되는 개발 패키지로 잘 하고 있다고 생각합니다. 이는 우리에게 큰 도움이 되었습니다.

그래도 3.1 릴리스를 곧 볼 수 있기를 바랍니다. :)

ILogger 의 더 나은 Cloudwatch 구체적인 구현이 있었으면 합니다. 이는 Lambda SDK를 사용할 때 ServiceCollection / ServiceProvider 더 잘 통합됩니다. 요청 컨텍스트 및 정적 LambdaLogger 클래스에서 제공되는 현재 버전은 기본적으로 단위 테스트/로그 출력 확인이 불가능하며 기본 .netcore ConsoleLogProvider 후킹하면 Cloudwatch 로그가 지저분해집니다.

ILogger 의 더 나은 Cloudwatch 구체적인 구현이 있었으면 합니다.

https://github.com/aws/aws-logging-dotnet#aspnet -core-logging 을 시도해 보셨습니까?

로그가 @CraigHead처럼 보이기를 원하십니까?

우리는 과거에 Serilog & https://github.com/structured-log/structured-log 를 사용하여 멋진 콘솔 로그와 Seq로 가져온 JSON 기반 로그를 출력했습니다. https://datalust.co/ 는 중앙 로그를 정말 멋진 형식으로 가져오는 가장 좋은 방법이었습니다.

@CraigHead Amazon.Lambda.Logging.AspNetCore 는 Lambda의 로깅을 IServiceCollection에 통합하기 위한 구현입니다. 그 라이브러리가 당신을 위해 작동하지 않습니까?

Lambda용 ttps://github.com/aws/aws-logging-dotnet#aspnet -core-logging의 AWS.Logger.AspNetCore 패키지는 권장하지 않습니다. 해당 라이브러리는 백그라운드 스레드를 사용하여 CloudWatch Logs에 로그를 푸시합니다. 이와 같은 백그라운드 스레드를 사용하면 함수 핸들러가 반환되자마자 Lambda 컴퓨팅 환경을 정지시키는 Lambda와 잘 작동하지 않습니다. 이는 백그라운드 스레드가 대기 중인 메시지를 플러시할 기회를 얻지 못할 수 있음을 의미합니다.

나는 이것에 대해 몰랐다. 팁 감사합니다!
SDK에서 Amazon.Lambda.Core.LambdaLogger 를 언급했습니다.
그 패키지( Amazon.Lambda.Logging.AspNetCore )를 확실히 확인하겠습니다.

https://docs.aws.amazon.com/lambda/latest/dg/csharp-logging.html

@clearwaterstream
람다 랜드 AFAIK에는 현재 인스턴스가 처리를 중지하거나 종료될 것임을 알리는 이벤트가 없으므로 귀하의 제안은 여전히 ​​버퍼링된 로그 이벤트를 비플러시(손실) 상태로 둡니다.

다른 필요를 위해 이 스레드를 가로채지 마십시오.
이 스레드는 AWS Lambda에서 .NET Core 3.1을 사용할 수 있을 때 몇 가지 정보를 제공하기 위해 생성되었습니다.
그리고 AWS에 우리가 그곳에서 기다리고 있다는 것을 알리기 위해.

3.1 릴리스에 람다 테스트 도구가 포함됩니까? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

그게 제 의도입니다. 작업은 mock-testtool-31 에서 진행 중 입니다. 3.1 분기의 큰 개선 사항은 사용자 Lambda 코드가 현재 별도의 AssemblyLoadContext에서 실행되고 있어 사용자가 현재 버전과 충돌하는 많은 버전을 수정해야 한다는 것입니다. AssemblyLoadContext 기능을 2.1 버전으로 다시 이식하려고 합니다.

참고로. 베어본 UI를 서버 측 Blazor 앱으로 변환하는 방법에 대해 논의하고 있습니다. Blazor 경험이 더 많은 사람이 그것이 좋은 아이디어인지 나쁜 아이디어인지에 대한 피드백이 있습니까?

참고로. 베어본 UI를 서버 측 Blazor 앱으로 변환하는 방법에 대해 논의하고 있습니다. Blazor 경험이 더 많은 사람이 그것이 좋은 아이디어인지 나쁜 아이디어인지에 대한 피드백이 있습니까?

이 시점에서 Blazor는 무엇이든 좋은 생각입니다. 특히 DotNet을 사용하는 사람들에게는 더욱 그렇습니다!

"barebones UI" - 이것은 .NET Core 3.1 Lambdas에 연결되지 않은 다른 앱입니까?
BTW, 나는 블레이저에 대해 전혀 신경 쓰지 않는다

@petarrepac 이것은 .NET Core 2.1 Lambda 함수를 디버그하는 데 도움이 되도록 제공한 AWS .NET Mock Lambda 테스트 도구를 참조했습니다. 다음은 참조용 게시물입니다. https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

.NET Core 3.1용 도구를 업데이트하는 중입니다.

@normj
아, 그것을 이해하지 못했습니다, 감사합니다
우리는 그런 도구가 필요하지 않았다는 것은 흥미로운 생각입니다.

우리의 관점에서 람다는 로컬에서 호출하고 로컬에서 테스트할 수 있는 베어본 AspNetCore HttpApi입니다.
유일한 차이점은 50줄의 코드 미만인 진입점 파일/클래스입니다.
또한 AWS에 배포할 때만 적절하게 테스트할 수 있는 항목이 많습니다.

• 권한
• 수신된 JSON 이벤트 및 컨텍스트의 모양
• ...
  따라서 다음의 조합:
• 로컬에서 실행되는 좋은 단위/통합 테스트
• 로컬 http 테스트
• 테스트 aws 환경에 배포하기 쉽습니다.
  멀리 갈 수 있습니다

아니면 명백한 시나리오를 놓치고 있습니까?

@petarrepac ASP.NET Core 브리지 사용의 가장 큰 장점 중 하나는 로컬에서 실행하기가 정말 쉽다는 것입니다. 가장 좋은 방법은 단위/통합 테스트를 사용하는 것이라는 데 동의하지만 애플리케이션 로직의 빠른 임시 테스트가 필요한 경우가 종종 있으며 이것이 이 도구가 좋은 이유입니다.

@normj님 감사합니다. Blazor와 관련하여 좋은 터치가 될 수 있습니다. 우리 팀의 사용 사례에서는 최소한 활용도가 낮을 ​​것입니다.

페이로드를 보내고 VS에서 코드를 단계별로 실행할 수 있을 만큼만 UI에 있습니다.

Lambda 부트스트래퍼와 사용자 지정 런타임 기능을 사용하여 하나의 코드 기반에서 여러 람다 함수를 확실히 달성할 수 있습니다.

"모놀리스"가 아닌 하나의 애플리케이션에서 배포되는 16개의 람다 제품군이 있습니다.

이는 블로그 게시물의 샘플 코드에 표시된 하드 코딩된 일대일 매핑 대신 _handler 환경 변수를 사용하여 런타임에 사용할 메서드를 선택하여 수행됩니다.

나는 그것을 시작할 때 어떤 행동이 "될"지를 알려주는 스위치를 수신하는 콘솔 앱이라고 생각합니다.

@martincostello

설명에 따라 이 문제를 해결하는 데 문제가 있습니다. 내 serverless.template의 해당 정의에 연결된 약 20개의 Lambda 함수가 내 Functions.cs에 있습니다. 호출할 함수를 나타내기 위해 각 정의와 함께 환경 변수를 전달한다는 것을 이해합니다. 이러한 기능의 대부분은 다음과 같은 서명입니다.

공개 APIGatewayProxyResponse ThisLambdaFunction(APIGatewayProxyRequest 요청, ILambdaContext 컨텍스트)
{

다른 인수(APIGatewayProxyRequest 제외)와 다른 반환 유형을 사용하는 다른 함수가 있는 경우 다른 람다 함수 서명에 대한 지원을 어떻게 추가합니까?

실을 탈선시키지 마십시오.

@twopointzero .NET Core 3.1 Custom Runtime 프로젝트를 사용하여 여러 람다 함수를 실행하는 솔루션을 Google에서 검색하는 데 며칠을 보냈습니다. 인터넷에 더 이상 관련 스레드가 없으며 내 문제에 대한 해결책이 있다는 희망의 희미한 빛을 제공한 기존 게시물에 답글을 달고 있습니다.

AWS에서 기본 .NET Core 3.1 지원이 없으면 삶이 어려워집니다. 최신 EntityFramewore Core 3.1.2로 업그레이드하려면 3.1로 업그레이드해야 합니다. 이 코어는 Aurora(PostgresSQL)의 연결 풀링에서 발생하는 문제를 수정합니다.

@normj ETA 금지 입장은

@antsaia 귀하의 의견은 .NET Core 3.1에 대한 AWS Lambda 지원과 관련이 아니라 사용자 지정 런타임 지원을 사용하는 분산 모놀

이 스레드를 탈선시키지 않기 위해 이것이 문제에 대한 나의 마지막 의견입니다.

@normj .net core 3.1 지원 구현 상태에 대한 정보를 얻을 수 있는 리소스(블로그, 포럼 등)가 있습니까?

나는 새로운 정보를 얻기 위해 매일 이 페이지를 방문하지만 분명히 정보가 충분하지 않습니다(해당 용도가 아니기 때문에). 미리 계획할 수 있도록 일종의 기본 업데이트가 있으면 훨씬 더 쉬워질 것입니다.

여기 많은 사람들과 마찬가지로 기능 제공 계획은 3.1을 사용할 수 있는지 또는 2.1을 사용하여 개발해야 하는지에 따라 크게 달라집니다. 제 경우에는 3.1이 System.Draw에 대한 지원을 제공할 것이며 이것은 제가 작업할 기능에 큰 영향을 미칩니다.

내가 원하는 것은.... 성 패트릭의 날은 람다 .net 코어 3.1 지원입니다.

@liam-sage 내가 찾을 수 있었던 것은 2020년 1분기에 준비될 것이라는 amazon 포럼의 몇 가지 게시물이었습니다. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@liam-sage 내가 찾을 수 있었던 것은 2020년 1분기에 준비될 것이라는 amazon 포럼의 몇 가지 게시물이었습니다. https://forums.aws.amazon.com/thread.jspa?threadID=313806

즉, 3월에 시작해야 합니다. 기다리고 있어

안녕, 나는 그것이 완전히 적합하지 않다는 것을 알고 있지만 dotnetcore 3.1로 업데이트된 자신의 람다를 얻을 수 있습니다. 그 동안 기다리는 동안 많은 람다를 만들어 고유한 dotnetcore 템플릿을 작성하는 것이 좋습니다. 나는 내 자신을 위해 그렇게 했다. 상용구 코드로 시간을 낭비할 필요가 없도록 하고 싶었습니다. 템플릿의 예는 여기 에서 찾을 수

그리고 Vincent, 거기에서 어떻게 호스팅합니까? 사용자 정의 런타임을 사용 중이신가요?
2020년 3월 5일 목요일 오후 7:40 Vincent van der Walt <
[email protected]>은 다음과 같이 썼습니다.

안녕, 나는 그것이 완전히 적합하지 않다는 것을 알고 있지만 자신의 람다를 얻을 수 있습니다
dotnetcore 3.1로 업데이트되었습니다. 그 동안 기다리는 동안 나는 제안 할 것입니다.
자신만의 dotnetcore 템플릿을 작성하기 위해 많은 람다를 만드는 경우. 나는 했다
내 자신을 위해. 시간을 낭비할 필요가 없도록 하고 싶었습니다.
상용구 코드. 템플릿의 예는 여기에서 찾을 수 있습니다.
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3LNVM
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

예, 사용자 정의 런타임을 사용합니다.

머신에서 로컬로 실행하거나 aws에 배포할 수 있습니다.

로컬의 경우 F5, aws에 대한 배포의 경우 dotnet lambda deploy-serverless

추가 정보는 템플릿을 로컬 컴퓨터에 설치하는 방법을 설명합니다(dotnetcore 템플릿).

사용자 지정 런타임은 훌륭하지만 프로덕션 환경에서 람다를 사용할 수 있도록 .Net Core 3.1에 대한 전체 AWS 지원을 기다리고 있습니다. 😄

받은 편지함에서 이것을 볼 때마다 @normj 가
적어도 조금 벗어난 게시물을 찾기 위해 무엇이든 발표했습니다.
주제. 다른 사람이 다른 사람에게 스레드를 가로채지 말라고 요청했지만 그렇지 않았습니다.
일했다. 누군가가 발표할 준비가 될 때까지 스레드를 잠글 수 있습니까?
3.1 지원 릴리스?

2020년 3월 6일 금요일 오전 7:13 bartoszsiekanski [email protected]
썼다:

사용자 지정 런타임은 훌륭하지만 여전히 전체 AWS 지원을 기다리고 있습니다.
람다용 .Net Core 3.1이 프로덕션 환경에서 사용하기 위해 😄

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVEXG43VM
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

.NET Core 3.1 지원에 대해 논의하는 것 외에는 별도의 문제를 만드십시오. @normj 소식이 더 나올 때까지 이 문제를

@hounddog22030 나는 내가 스레드를 '하이재킹'하고 있다는 것을 깨닫지 못했습니다. 나는 사람들이 dotnetcore 3.1로 전환하기를 필사적으로 한다면 준비가 되었는지 끊임없이 묻는 것보다 대안적인 접근 방식이 있다고 제안했습니다. 공식 비 사용자 지정 런타임 지원이 준비되면 준비됩니다. 사람들은 조금 더 인내하거나 다른 접근 방식을 찾아야 합니다.

AWS가 dotnet lambda package 명령에서 --self-contained 옵션을 지원하는 경우 람다 함수는 SDK 버전에 관계없이 실행 가능해야 합니다. 오른쪽? 모든 .NET Core 릴리스에 대한 지원을 추가하는 대신 그렇게 하지 않는 이유는 무엇입니까?

AWS가 dotnet lambda package 명령에서 --self-contained 옵션을 지원하는 경우 람다 함수는 SDK 버전에 관계없이 실행 가능해야 합니다. 오른쪽? 모든 .NET Core 릴리스에 대한 지원을 추가하는 대신 그렇게 하지 않는 이유는 무엇입니까?

방금 람다 사용자 지정 런타임 기능을 설명했습니다.

@aussiearef 실제로 잘 작동하지만 자체 포함 패키지에는 .Net Core 자체가 포함되어 있으며 일반적으로 웹 사이트에 대해 최소 40MB(압축)를 추가하므로 애플리케이션과 종속성 자체를 위한 공간이 많지 않습니다.

동일한 버전의 .NET Core를 사용하는 경우 사용자 지정 런타임도 기본 런타임보다 느립니다(콜드 스타트). 3.1은 많은 성능 개선 사항을 추가하므로 3.1 사용자 정의 완전 최적화와 2.1 기본 간에 동일한 수준의 성능을 기대할 수 있습니다. 3.1 네이티브가 상당한 개선을 가져올 것이라는 희망이 있습니다.

Q1은 4일 후에 종료되지만 람다에서는 3.1을 볼 수 없을 것 같습니다.
이 팬데믹 시기에 팀의 모든 구성원이 안전하기를 바라며 2분기에 이 릴리스를 볼 수 있기를 바랍니다.

며칠 남지 않았다는 희망을 버리지 마세요! 우리는 모두 최종 배포 및 기타 막바지 활동을 기다리는 것으로 거의 마무리되었습니다. 우리는 모두 소프트웨어를 알고 있으며 막판에 딸꾹질이 있을 수 있음을 명심하십시오.

저는 실제로 런타임이 열리면 모든 것을 사용할 수 있도록 곧 새로운 클라이언트 도구 업데이트 롤아웃을 시작할 계획입니다. 따라서 새로운 NuGet 패키지 업데이트가 표시되는 경우 런타임이 있다고 가정하지 마십시오. 블로그 게시물이 나올 때까지 기다리면 여기에 업데이트를 게시하겠습니다.

환상적인 소식입니다. @normj 감사합니다

블로그 게시물 및 출시를 기대합니다.

며칠 남지 않았다는 희망을 버리지 마세요! 우리는 모두 최종 배포 및 기타 막바지 활동을 기다리는 것으로 거의 마무리되었습니다. 우리는 모두 소프트웨어를 알고 있으며 막판에 딸꾹질이 있을 수 있음을 명심하십시오.

저는 실제로 런타임이 열리면 모든 것을 사용할 수 있도록 곧 새로운 클라이언트 도구 업데이트 롤아웃을 시작할 계획입니다. 따라서 새로운 NuGet 패키지 업데이트가 표시되는 경우 런타임이 있다고 가정하지 마십시오. 블로그 게시물이 나올 때까지 기다리면 여기에 업데이트를 게시하겠습니다.

이 스레드의 태도에 대한 당신의 인내심은 인상적이지 않습니다. 작업해 주셔서 감사합니다!

@normj 는 게시하기 전에 수행할 수 있는 모든 테스트를 기꺼이 도와드립니다 ;)

앞으로 2일이 더 남았고 손가락이 넘어졌다.

그리고 쿼터 13시간 남았습니다 😂

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

기다려 주셔서 감사합니다. @raRaRa 이 호를 마감하는 영광을 여러분께 남겨 드리겠습니다.

엄청난

2020년 3월 31일 화요일 20:06 Norm Johanson, [email protected] 작성:

그리고 쿼터 13시간 남았습니다 😂

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

기다려 주셔서 감사합니다. @raRaRa https://github.com/raRaRa
이 문제를 마무리하는 영광을 여러분께 남겨 드리겠습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANNCNFSM4JU5UTJA
.

감사 해요!!!!

그리고.... 구독 취소 :-)

관계자 여러분 감사합니다!!!

감사 해요!

그리고 쿼터 13시간 남았습니다 😂

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

기다려 주셔서 감사합니다. @raRaRa 이 호를 마감하는 영광을 여러분께 남겨 드리겠습니다.

잘 하셨어요!

바로 AWS 베이비입니다. 바로 AWS입니다!!!
무슨 일이 일어나든 결국 그들은 해냅니다.

고마워요, 팀!!!

좋은 소식과 감사합니다 @raRaRa @normj !!! 어리석고 탐욕스럽게 들릴 위험이 있지만 본질적으로 Powershell 7도 의미합니까? 확인만 하고.......

@normj 와 AWS의 모두

아래로 스크롤 내리시는 분들을 위한 블로그 링크입니다.
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

굉장합니다. dotnet core 3.1에 대한 지원을 추가해 주셔서 감사합니다!!!

@andyKalman 아직 PowerShell 7에는 없습니다. AWSLambdaPSCore 모듈에 대한 최종 수정 작업을 수행하고 있으며 갤러리에 AWSLambdaPSCore 2.0.0 버전이 릴리스됩니다.

빠른 답변 감사합니다 @normj . 나는 그것이 빠른 후속 조치로 보이는 것을 보니 너무 좋은 사실 이후에 #607을 보았습니다. 여기에서 댓글을 중단할 수 있도록 추적할 다른 문제가 있습니까? :) 다시 한 번 감사합니다.

축하 해요!
그리고 AWS와 .NET 팀에 감사드립니다!
매우 감사.

이 일을 할 수 있도록 도와주신 모든 분들께 감사드립니다! 이것은 엄청난 릴리스이며 많은 노력을 기울였음을 보여줍니다! 멋진! 🎉🥳

감사 해요 !! : 박수:: 박수:: 따다:: 따다:

축하합니다. 업그레이드를 기대합니다.

감사 해요!

이 람다를 업그레이드하고 싶은 멋진 작품입니다.

훌륭한 일! @normj 감사합니다

멋진 작업 팀!

dotnet 3.1 Async Streams + AWS AppSync/GraphQL 구독으로 Lambda 작업자에 뛰어들기를 열망합니다.
AWS 팀, 대단히 감사합니다!

OMG, 당신이 지배하는 녀석들! 놀라운! 우후! 😄😄😄

감사 해요!

@andyKalman 현재 PowerShell 7을 사용하는 AWSLambdaPSCore 모듈 버전 2.0.0을 출시했습니다. PS7 지원에 대한 블로그 게시물을 올릴 계획이지만 기존 PowerShell 6 지원에서 7만 사용하는 것과 동일하게 작동합니다.

@andyKalman 현재 PowerShell 7을 사용하는 AWSLambdaPSCore 모듈 버전 2.0.0을 출시했습니다. PS7 지원에 대한 블로그 게시물을 올릴 계획이지만 기존 PowerShell 6 지원에서 7만 사용하는 것과 동일하게 작동합니다.

새 버전으로 게시하면 새 버전의 AWSLambdaPSCore가 기존 Lambda 함수 내의 구성을 업데이트합니까? dotnet3.1 및 ps7을 가리킬까요?

@tr33squid 예 2.0.0으로 배포하는 경우 .NET Core 3.1 및 PS7을 사용합니다.

정말 감사하고 훌륭합니다 AWS 팀!!

안녕하세요 여러분,

저는 Lambda에서 .NET Core 3.1에 대한 지원을 가져오기 위해 적극적으로 노력하고 있습니다. Microsoft에서 런타임을 빌드하는 방법에 많은 작업을 수행했기 때문에 시간이 걸립니다. 네이티브 런타임을 제공하기 위해 이러한 변경 사항을 통합하는 작업을 하고 있습니다.

AWS-Lambda .NET 코어 팀 덕분에

안녕하세요,
AWS-Lambda를 실행하려고 할 때 이 오류가 발생합니다.
호환되는 프레임워크 버전을 찾을 수 없습니다.
지정된 프레임워크 'Microsoft.AspNetCore.App', 버전 '3.1.0'을 찾을 수 없습니다.
어떤 제안 ??

안녕하세요,
AWS-Lambda를 실행하려고 할 때 이 오류가 발생합니다.
호환되는 프레임워크 버전을 찾을 수 없습니다.
지정된 프레임워크 'Microsoft.AspNetCore.App', 버전 '3.1.0'을 찾을 수 없습니다.
어떤 제안 ??

3.1.0 SDK를 설치해야 합니다.

프로젝트에서 Microsoft.AspNetCore.App을 제거해야 한다고 생각합니다.
Core 3.1.0에 더 이상 필요하지 않은 종속성,
2.1에서 업그레이드한 서비스를 빌드하고 배포합니다.

2020년 4월 24일 금요일 오전 3:24 Gregory Lyons [email protected]
썼다:

안녕하세요,
AWS-Lambda를 실행하려고 할 때 이 오류가 발생합니다.
호환되는 프레임워크 버전을 찾을 수 없습니다.
지정된 프레임워크 'Microsoft.AspNetCore.App', 버전 '3.1.0'은(는)
찾을 수 없습니다.
어떤 제안 ??

3.1.0 SDK를 설치해야 합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANNCNFSM4JU5UTJA
.

--
최상의,
성 조지

조지 타코스
수석 솔루션 아키텍트

WeAre8
230 파크 애비뉴, 3층 서쪽
뉴욕, NY 10169
(917) 717-9067
wear8.com

개인 출입구,
71 밴더빌트 애비뉴
3 층

Microsoft.AspNetCore.App이 프로젝트 종속성에서 제거되어야 한다고 생각합니다. Core 3.1.0에는 더 이상 필요하지 않습니다. 2.1에서 업그레이드한 서비스를 빌드하고 배포하기 위해 제거해야 했습니다.
…
2020년 4월 24일 금요일 오전 3:24 Gregory Lyons @ . * > 쓰기: 안녕하세요, AWS-Lambda를 실행하려고 할 때 이 오류가 발생합니다. 호환되는 프레임워크 버전을 찾을 수 없습니다. 지정된 프레임워크 'Microsoft.AspNetCore.App', 버전 '3.1.0'을 찾을 수 없습니다. 어떤 제안 ?? 3.1.0 SDK를 설치해야 합니다. — 이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다. 이 이메일에 직접 회신하거나 GitHub < #554 (comment) >에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA 구독을 취소합니다.
-- 베스트, George George Taskos 선임 솔루션 설계자 WeAre8 230 Park Avenue, 3층. West New York, NY 10169 (917) 717-9067 weare8.com Private Entrance, 71 Vanderbilt Ave 3rd Floor

답장을 보내 주셔서 감사합니다,
사실 이 오류는 내 어리석은 실수 때문이었습니다. 내 serverless.yml에서 runtime: dotnetcore2.1을 제거하는 것을 잊었습니다. 이제 문제가 해결되었습니다.

누구든지 이에 대한 업데이트된 벤치마크/비교를 수행합니까? 내가 찾을 수있는 것은 사용자 정의 런타임이있는 오래된 것뿐입니다.

누구든지 이에 대한 업데이트된 벤치마크/비교를 수행합니까? 내가 찾을 수있는 것은 사용자 정의 런타임이있는 오래된 것뿐입니다.

여기 좋은 것이 있습니다.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

또한 512mb 람다 크기에서 2.1 복합 람다를 3.1로 업데이트한 개인적인 경험에 따르면 거의 동일한 성능(콜드 및 웜 스타트)이 나타났습니다. 2.1 및 3.1 람다는 모두 람다 계층, 최적화된 게시, newtonsoft(3.1에서 Microsoft json으로 성능 향상을 볼 수 있음), 계층화된 컴파일 및 3.1용 RTR을 사용합니다.

내 지표에 따르면 dotnet 3.1 런타임에서는 약간의 성능이 향상되지만 Amazon Linux 2 및 dotnet 3.1 초기화에서는 성능이 저하됩니다. (2.1은 Amazon Linux 1을 사용합니다.) 수익을 창출합니다.