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?itok=KnbqzkcZ)
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?itok=3yo11TXe)
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?itok=GYiuVcPX)
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?itok=yAPPu9DX)
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 (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit