Red Hat is on a journey to build a functionally safe Linux, targeting the automotive industry with multiple partners. On this journey, Red Hat is committed to working transparently for this new in-vehicle operating system in the same way it does for RHEL. This commitment has led to the creation of the CentOS Automotive Special Interest Group (SIG).
The CentOS Automotive SIG produces three artifacts:
- An RPM repository named AutoSD (Automotive Stream Distribution), which is the upstream, in-development version of the future Red Hat product Red Hat In-Vehicle Operating System. AutoSD can be considered to be the CentOS Stream of Red Hat's in-vehicle OS.
- An RPM repository for the Automotive SIG serving as a dedicated space for conducting experiments, incorporating new packages, or making available newer package versions to AutoSD before they are in CentOS Stream or AutoSD itself.
- A set of OSBuild manifests for building sample images from the repositories above (and possibly others). These manifests can produce sample/proof-of-concept images in various formats (.qcow2, ext4 filesystem, oci tarball, rootfs, and so on). You can use these manifests to get started, but you would create your own to adjust the images you want to build as you need.
We've created automation to build the developer
sample image in the form of an Amazon Machine Image (AMI) that is then automatically uploaded into AWS and made available for anyone to use. That automation happens nightly, so you'll be able to get bug fixes and new features quickly and find issues early, should you have any!
If you're curious about what AutoSD looks like, or you want to test something with it quickly, or to build automation on top of it, and have access to AWS, then have a look at these images.
Manual provisioning from the AWS Console
At the time of this writing, developer images are only available in us-east-2 regions.
From the AWS Console menu, go to Services -> Compute -> EC2:
![AWS Console: Choose EC2 from the services menu](/rhdc/managed-files/styles/wysiwyg_full_width/private/autosd-images-aws-img1.png.webp?itok=Yi6tdvwl)
Click on the Launch Instance button:
![AWS Console: launch new instance button](/rhdc/managed-files/styles/wysiwyg_full_width/private/autosd-images-aws-img2.png.webp?itok=qPgM4T5O)
Set a name of your choice and then click on Browse More AMIs:
![AWS Console: Browser the AMI catalog button](/rhdc/managed-files/styles/wysiwyg_full_width/private/autosd-images-aws-img3.png.webp?itok=w4Q55qp7)
Select Community AMIs, type "auto-osbuild" in the search field, and choose an architecture of your choice (x86_64 or aarch64 at the time of this writing):
![AWS Console: search for “auto-osbuild” images in the AMI catalog](/rhdc/managed-files/styles/wysiwyg_full_width/private/autosd-images-aws-img4.png.webp?itok=CQEyhmsK)
You can then follow with the usual EC2 setup, pick a machine type, keypair, and so on.
Automated provisioning with Terraform
It's also possible to quickly provision an AutoSD machine in AWS using any infrastructure/configuration as code tool.
The following sample code demonstrates how to do it with Terraform:
terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 4.16" } } required_version = ">= 1.2.0" } provider "aws" { region = "us-east-2" } resource "aws_vpc" "autosd_demo_vpc" { cidr_block = "10.0.0.0/16" tags = { Name = "autosd-demo-vpc" } } resource "aws_subnet" "autosd_demo_subnet_public" { vpc_id = aws_vpc.autosd_demo_vpc.id cidr_block = "10.0.1.0/24" availability_zone = "us-east-2a" tags = { Name = "autosd-demo-subnet-public" } } resource "aws_subnet" "autosd_demo_subnet_private" { vpc_id = aws_vpc.autosd_demo_vpc.id cidr_block = "10.0.2.0/24" availability_zone = "us-east-2a" tags = { Name = "autosd-demo-subnet-private" } } resource "aws_internet_gateway" "autosd_demo_ig" { vpc_id = aws_vpc.autosd_demo_vpc.id tags = { Name = "autosd-demo-ig" } } resource "aws_route_table" "autosd_demo_rt" { vpc_id = aws_vpc.autosd_demo_vpc.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.autosd_demo_ig.id } route { ipv6_cidr_block = "::/0" gateway_id = aws_internet_gateway.autosd_demo_ig.id } tags = { Name = "autosd-demo-rt" } } resource "aws_route_table_association" "public_1_rt_a" { subnet_id = aws_subnet.autosd_demo_subnet_public.id route_table_id = aws_route_table.autosd_demo_rt.id } resource "aws_security_group" "autosd_demo_sg" { name = "autosd-demo-sg" vpc_id = aws_vpc.autosd_demo_vpc.id ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = -1 cidr_blocks = ["0.0.0.0/0"] } } resource "aws_instance" "autosd_demo" { ami = "ami-0dec5dbda62a236b3" instance_type = "t3a.nano" key_name = "autosd-demo" subnet_id = aws_subnet.autosd_demo_subnet_public.id vpc_security_group_ids = [aws_security_group.autosd_demo_sg.id] associate_public_ip_address = true tags = { Platform = "AutoSD" } } output "autosd_demo_public_ip" { value = ["${aws_instance.autosd_demo.*.public_ip}"] }
You can get the instance's raw public IP by running the following command:
terraform output -json autosd_demo_public_ip | jq '.[0][0]' | tr -d \"
Here are a few notes when using automation tools to deploy an AutoSD developer machine:
- The AMI is only available in the us-east-2 region.
- Some machine types will return an error because they are not compatible with UEFI booting.
- Deploying in such a way requires extra VPC configuration, and some of those recipes need to be allocated in us-east-2 "sub-regions" such as us-east-2a, us-east-2b, or us-east-2c.
- The above code requires a keypair (pem file) to already exist as it references one by its name. Use the name to SSH into the VM using the ec2-user username.
Wrap up
Once built, you're able to SSH into your instance (using a keypair) and check the kernel (spoiler: these images have a different kernel than the one available in CentOS stream and RHEL). Run Podman, BlueChi, and QM to see how these AutoSD images meet your needs.
These developer images have about 40GB of storage available. Let us know if you need more.
저자 소개
Pierre-Yves Chibon (aka pingou) is a Principal Software Engineer who spent nearly 15 years in the Fedora community and is now looking at the challenges the automotive industry offers to the FOSS ecosystems.
Joined Red Hat in March 2016 in its Mobile platform as an engineer and has worked in several engineering projects since. Currently works with other upstream automotive communities and the CentOS Automotive SIG.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.