DevOps'u elimizden geldiğince geliştirdik. 8 kişiydik ve Vasya Windows'un en havalısıydı. Aniden Vasya ayrıldı ve bana Windows geliştirme tarafından sağlanan yeni bir proje başlatma görevi verildi. Tüm Windows geliştirme yığınını masaya bıraktığımda durumun ne kadar acı verici olduğunu fark ettim...
Hikaye böyle başlıyor Alexandra Sinchinova üzerinde . Önde gelen Windows uzmanı şirketten ayrıldığında Alexander şimdi ne yapacağını merak etti. Tabii ki Linux'a geçin! Alexander, 100 son kullanıcı için tamamlanmış bir proje örneğini kullanarak size nasıl bir emsal oluşturmayı ve Windows geliştirmenin bir bölümünü Linux'a aktarmayı başardığını anlatacak.
TFS, Puppet, Linux .NET çekirdeğini kullanarak bir projeyi RPM'ye kolayca ve zahmetsizce nasıl teslim edebilirim? Geliştirme ekibi Postgres ve Flyway kelimelerini ilk kez duyarsa ve son teslim tarihi yarından sonraki günse, proje veritabanının sürümlendirilmesi nasıl desteklenir? Docker ile nasıl entegre olunur? .NET geliştiricilerini Windows'u ve smoothie'leri bırakıp Puppet ve Linux'u tercih etmeye nasıl motive edebiliriz? Windows'u üretimde tutacak güç, istek veya kaynaklar yoksa ideolojik çatışmalar nasıl çözülebilir? Alexander'ın raporunun transkriptinde bunun yanı sıra Web Dağıtımı, test etme, CI, mevcut projelerde TFS kullanma uygulamaları ve tabii ki kırık koltuk değnekleri ve çalışma çözümleri hakkında.
Böylece Vasya gitti, görev bende, geliştiriciler dirgenlerle sabırsızlıkla bekliyorlar. Sonunda Vasya'nın iade edilemeyeceğini anlayınca işe koyuldum. Başlangıç olarak filomuzdaki Win VM'lerin yüzdesini değerlendirdim. Skor Windows lehine değildi.
DevOps'u aktif olarak geliştirdiğimiz için yeni bir uygulama sunma yaklaşımında bir şeylerin değiştirilmesi gerektiğini fark ettim. Tek bir çözüm vardı; mümkünse her şeyi Linux'a aktarmak. Google bana yardımcı oldu; o zamanlar .Net zaten Linux'a taşınmıştı ve çözümün bu olduğunu fark ettim!
Neden .NET core Linux ile birlikte?
Bunun birkaç nedeni vardı. "Para öde" ile "ödeme" arasında çoğunluk benim gibi ikinciyi seçecek. MSDB lisansının maliyeti yaklaşık 1 ABD dolarıdır; Windows sanal makinelerinden oluşan bir filonun bakımı yüzlerce dolara mal olur. Büyük bir şirket için bu büyük bir masraftır. Bu yüzden tasarruf - ilk sebep. En önemlisi değil ama önemli olanlardan biri.
Windows sanal makineleri Linux'lu kardeşlerinden daha fazla kaynak tüketiyor - onlar ağır. Büyük şirketin ölçeği göz önüne alındığında Linux'u seçtik.
Sistem mevcut CI'ya kolayca entegre edilir. Kendimizi ilerici DevOps olarak görüyoruz, Bamboo, Jenkins ve GitLab CI kullanıyoruz, dolayısıyla işlerimizin çoğu Linux üzerinde çalışıyor.
Son sebep ise uygun eşlik. Teknik kısmı anlayan, kesintisiz hizmet sağlayan ve hizmetleri ikinci hattan sürdüren "eskortlar" için giriş engelini azaltmamız gerekiyordu. Zaten Linux yığınına aşinaydılar, bu nedenle yeni bir ürünü anlamaları, desteklemeleri ve bakımını yapmaları, Windows platformu için yazılımın aynı işlevselliğini anlamak için ek kaynaklar harcamaktan çok daha kolaydır.
Gereksinimler
İlk ve en önemli - geliştiriciler için yeni çözümün rahatlığı. Özellikle Linux sözcüğü söylendikten sonra hepsi değişime hazır değildi. Geliştiriciler, derlemeler ve smoothie'ler için otomatik testlere sahip en sevdikleri Visual Studio, TFS'yi istiyor. Üretime teslimatın nasıl gerçekleştiği onlar için önemli değil. Bu nedenle, olağan süreci değiştirmemeye ve Windows geliştirme için her şeyi değiştirmeden bırakmaya karar verdik.
Yeni projeye ihtiyaç var mevcut CI'ya entegre olma. Raylar zaten oradaydı ve tüm çalışmaların konfigürasyon yönetim sisteminin parametreleri, kabul edilen teslimat standartları ve izleme sistemleri dikkate alınarak yapılması gerekiyordu.
Destek ve kullanım kolaylığıFarklı bölümlerden ve destek departmanından tüm yeni katılımcılar için minimum giriş eşiğinin bir koşulu olarak.
Son tarih - dün.
Win Geliştirme Grubu
O zamanlar Windows ekibi neyle çalışıyordu?
Artık şunu rahatlıkla söyleyebilirim IdentityServer4 benzer yeteneklere sahip ADFS'ye harika bir ücretsiz alternatif veya Entity Framework Çekirdeği - geliştiriciler için SQL komut dosyaları yazma zahmetine girmeyeceğiniz, ancak veritabanındaki sorguları OOP terimleriyle tanımlayabileceğiniz bir cennet. Ancak daha sonra eylem planı tartışılırken bu yığına sanki Sümer çivi yazısıymış gibi baktım, sadece PostgreSQL ve Git'i tanıyordum.
O zamanlar aktif olarak kullanıyorduk. Kukla Bir konfigürasyon yönetim sistemi olarak. Çoğu projemizde kullandık GitLab CI, Elastik, dengeli yüksek yük hizmetleri kullanarak HAProxy her şeyi onunla izledi Zabbix, bağlar grafana и Prometheus, Jaegerve bunların hepsi demir parçalarının üzerinde dönüyordu HP c ESXi üzerinde VMware. Herkes bunu biliyor; türün bir klasiği.
Tüm bu müdahalelere başlamadan önce neler olduğuna bakalım ve anlamaya çalışalım.
Neydi
TFS, yalnızca geliştiriciden son üretim makinesine kod iletmekle kalmayan, aynı zamanda platformlar arası düzeyde CI sağlamak için çeşitli hizmetlerle çok esnek entegrasyona yönelik bir sete sahip olan oldukça güçlü bir sistemdir.
Daha önce bunlar sağlam pencerelerdi. TFS, birçok projeyi birleştirmek için kullanılan çeşitli Build aracılarını kullandı. Her temsilcinin görevleri paralelleştirmek ve süreci optimize etmek için 3-4 çalışanı vardır. Ardından, sürüm planlarına göre TFS, yeni hazırlanan Build'i Windows uygulama sunucusuna teslim etti.
Neyi başarmak istedik?
Teslimat ve geliştirme için TFS'yi kullanıyoruz ve uygulamayı bir Linux Uygulama sunucusunda çalıştırıyoruz ve aralarında bir tür sihir var. Bu Sihirli kutu ve önümüzde işin tuzu var. Parçalara ayırmadan önce bir adım kenara çekilip uygulama hakkında birkaç söz söyleyeceğim.
Proje
Uygulama, ön ödemeli kartların işlenmesine yönelik işlevsellik sağlar.
müşteri
İki tür kullanıcı vardı. Ilk SSL SHA-2 sertifikası kullanarak giriş yaparak erişim kazandınız. sen ikinci bir kullanıcı adı ve şifre kullanılarak erişim vardı.
HAProxy
Daha sonra müşteri isteği HAProxy'ye gitti ve bu da aşağıdaki sorunları çözdü:
- birincil yetkilendirme;
- SSL sonlandırma;
- HTTP isteklerini ayarlama;
- yayın istekleri.
İstemci sertifikası zincir boyunca doğrulandı. Biz - yetki ve biz kendimiz hizmet müşterilerine sertifika verdiğimiz için bunu karşılayabiliriz.
Üçüncü noktaya dikkat edin, ona biraz sonra döneceğiz.
Backend
Arka ucu Linux'ta yapmayı planladılar. Arka uç, veritabanıyla etkileşime girer, gerekli ayrıcalık listesini yükler ve ardından yetkili kullanıcının hangi ayrıcalıklara sahip olduğuna bağlı olarak, mali belgeleri imzalamak ve bunları yürütülmek üzere göndermek veya bir tür rapor oluşturmak için erişim sağlar.
HAProxy ile tasarruf
Her müşterinin gezindiği iki bağlama ek olarak bir de kimlik bağlamı vardı. IdentityServer4 sadece giriş yapmanızı sağlar, bu ücretsiz ve güçlü bir analogdur ADFS - Active Directory Federasyon Hizmetleri.
Kimlik isteği birkaç adımda işlendi. İlk adım - müşteri arka uca girdimBu sunucuyla iletişim kuran ve istemci için bir belirtecin varlığını kontrol eden. Bulunamazsa, istek geldiği bağlama geri döndürüldü, ancak bir yönlendirmeyle ve yönlendirmeyle birlikte kimliğe gitti.
İkinci adım - istek alındı IdentityServer'daki yetkilendirme sayfasına, istemcinin kayıtlı olduğu ve uzun zamandır beklenen jetonun IdentityServer veritabanında göründüğü yer.
Üçüncü adım - müşteri geri yönlendirildi geldiği bağlama göre.
IdentityServer4'ün bir özelliği vardır: HTTP yoluyla dönüş isteğine verilen yanıtı döndürür. Sunucuyu kurmakta ne kadar uğraşırsak uğraşalım, dokümantasyon konusunda kendimizi ne kadar aydınlatsak da, her defasında HTTPS yoluyla gelen bir URL ile ilk istemci isteği aldık ve IdentityServer aynı bağlamı HTTP ile döndürdü. Şok olduk! Tüm bunları kimlik bağlamı aracılığıyla HAProxy'ye aktardık ve başlıklarda HTTP protokolünü HTTPS olarak değiştirmek zorunda kaldık.
İyileştirme nedir ve nerede tasarruf ettiniz?
IdentityServer4'ü ayrı bir segmentte ayrı bir düğüm olarak yerleştirmediğimiz ve uygulamanın arka ucunun çalıştığı aynı sunucuda arka uçla birlikte kullandığımız için, bir grup kullanıcıyı ve kaynağı yetkilendirmek için ücretsiz bir çözüm kullanarak paradan tasarruf ettik. .
Nasıl çalışması gerektiği
Söz verdiğim gibi - Magic Box. Linux'a yöneleceğimizin garanti olduğunu zaten anlıyoruz. Çözüm gerektiren belirli görevleri formüle edelim.
Kukla ortaya çıkıyor. Hizmet ve uygulama yapılandırmasını sunmak ve yönetmek için harika tarifler yazılması gerekiyordu. Bir rulo kalem, bunun ne kadar hızlı ve verimli bir şekilde yapıldığını anlamlı bir şekilde gösterir.
Teslimat Yöntemi. Standart RPM'dir. Herkes Linux'ta onsuz yapamayacağınızı anlıyor, ancak projenin kendisi montajdan sonra bir dizi yürütülebilir DLL dosyasıydı. Yaklaşık 150 kişi vardı, proje oldukça zordu. Tek uyumlu çözüm, bu ikili dosyayı RPM'ye paketlemek ve uygulamayı ondan dağıtmaktır.
Sürüm oluşturma. Çok sık yayınlamamız gerekiyordu ve paket adını nasıl oluşturacağımıza karar vermemiz gerekiyordu. Bu TFS ile entegrasyon düzeyi meselesidir. Linux'ta bir yapı aracımız vardı. TFS, bir işleyiciye (işçiye) Build aracısına bir görev gönderdiğinde, aynı zamanda işleyici işleminin ortamında ortaya çıkan bir dizi değişkeni de ona iletir. Bu ortam değişkenleri Yapı adını, sürüm adını ve diğer değişkenleri içerir. Bununla ilgili daha fazla bilgiyi “RPM paketi oluşturma” bölümünde okuyun.
TFS'yi ayarlama Pipeline'ı kurmaya geldi. Daha önce tüm Windows projelerini Windows aracılarında topluyorduk, ancak şimdi bir Linux aracısı beliriyor - derleme grubuna dahil edilmesi gereken, bazı yapıtlarla zenginleştirilmiş ve bu Yapı aracısı üzerinde ne tür projelerin oluşturulacağını söyleyen bir Yapı aracısı ve bir şekilde Pipeline'ı değiştirin.
IdentityServer. ADFS bizim yolumuz değil, Açık Kaynak'a gidiyoruz.
Bileşenleri inceleyelim.
Sihirli kutu
Dört bölümden oluşmaktadır.
Linux Yapı aracısı. Linux, çünkü biz onun için geliştiriyoruz; bu mantıklı. Bu kısım üç adımda yapıldı.
- Çalışanları yapılandırma ve yalnız değil, çünkü projede dağıtılmış çalışma bekleniyordu.
- .NET Core 1.x'i yükleyin. Standart depoda 1 zaten mevcutken neden 2.0.x? Çünkü geliştirmeye başladığımızda stabil sürüm 1.09 idi ve projenin buna göre yapılmasına karar verildi.
- Git 2.x.
RPM deposu. RPM paketlerinin bir yerde saklanması gerekiyordu. Tüm Linux ana bilgisayarlarının kullanabileceği aynı kurumsal RPM deposunu kullanacağımız varsayılmıştı. Onlar da öyle yaptılar. Depo sunucusu yapılandırıldı ağ kancası gerekli RPM paketini belirtilen konumdan indiren. Paket sürümü, Build aracısı tarafından webhook'a bildirildi.
GitLab. Dikkat! GitLab, geliştiriciler tarafından değil, operasyon departmanı tarafından uygulama sürümlerini, paket sürümlerini kontrol etmek, tüm Linux makinelerinin durumunu izlemek için kullanılıyor ve tarifi - tüm Puppet manifestolarını - saklıyor.
Kukla — tüm tartışmalı sorunları çözer ve tam olarak Gitlab'dan istediğimiz yapılandırmayı sunar.
Dalmaya başlıyoruz. RPM'ye DLL teslimi nasıl çalışır?
DDL'yi RPM'ye teslim etme
Diyelim ki bir .NET geliştirme rock yıldızımız var. Visual Studio'yu kullanır ve bir yayın dalı oluşturur. Bundan sonra Git'e yükler ve buradaki Git bir TFS varlığıdır, yani geliştiricinin çalıştığı uygulama deposudur.
Bundan sonra TFS yeni bir taahhüdün geldiğini görür. Hangi uygulama? TFS ayarlarında, belirli bir Build aracısının hangi kaynaklara sahip olduğunu gösteren bir etiket vardır. Bu durumda bir .NET Core projesi oluşturduğumuzu görüyor ve havuzdan bir Linux Build aracısı seçiyor.
Yapı aracısı kaynakları alır ve gerekli olanı indirir bağımlılıklar .NET deposundan, npm'den vb. ve uygulamanın kendisini ve sonraki paketlemeyi oluşturduktan sonra RPM paketini RPM deposuna gönderir.
Öte yandan şöyle bir olay yaşanıyor. Operasyon departmanı mühendisi projenin kullanıma sunulmasında doğrudan yer alır: paketlerin versiyonlarını değiştirir. Hiera uygulama tarifinin saklandığı depoda, ardından Puppet tetiklenir Yum, yeni paketi depodan alır ve uygulamanın yeni sürümü kullanıma hazırdır.
Kelimelerle her şey basit ama Build aracısının içinde neler oluyor?
Paketleme DLL RPM'si
TFS'den proje kaynakları ve derleme görevi alındı. Oluşturma aracısı kaynaklardan projeyi kendisi oluşturmaya başlar. Birleştirilmiş proje set olarak mevcuttur DLL dosyalarıDosya sistemindeki yükü azaltmak için zip arşivinde paketlenmiştir.
ZIP arşivi atılır RPM paketi oluşturma dizinine. Daha sonra Bash betiği ortam değişkenlerini başlatır, Derleme sürümünü, proje sürümünü, derleme dizininin yolunu bulur ve RPM-build'i çalıştırır. Derleme tamamlandıktan sonra paket şuraya yayınlanır: yerel depoYapı aracısında bulunur.
Daha sonra, Build aracısından RPM deposundaki sunucuya JSON isteği gönderildi sürümün ve yapının adını belirten. Daha önce bahsettiğim Webhook, bu paketi Build aracısındaki yerel depodan indiriyor ve yeni derlemeyi kuruluma hazır hale getiriyor.
Neden RPM deposuna bu özel paket dağıtım şeması? Birleştirilmiş paketi neden hemen depoya gönderemiyorum? Gerçek şu ki bu, güvenliğin sağlanmasının bir koşuludur. Bu senaryo, yetkisiz kişilerin RPM paketlerini tüm Linux makinelerinin erişebildiği bir sunucuya yükleme olasılığını sınırlar.
Veritabanı versiyonlama
Geliştirme ekibiyle yaptığımız istişarede, MS SQL'e daha yakın oldukları ortaya çıktı, ancak Windows dışı projelerin çoğunda zaten PostgreSQL'i tüm gücüyle kullanıyorduk. Zaten ödenen her şeyden vazgeçmeye karar verdiğimiz için burada da PostgreSQL kullanmaya başladık.
Bu bölümde veritabanını nasıl versiyonladığımızı ve Flyway ile Entity Framework Core arasında nasıl seçim yaptığımızı anlatmak istiyorum. Artılarına ve eksilerine bakalım.
Eksileri
Flyway sadece tek yöne gider, biz geri dönemeyiz - bu önemli bir dezavantajdır. Geliştiricinin rahatlığı açısından bunu Entity Framework Core ile başka şekillerde karşılaştırabilirsiniz. Hatırlarsınız, bunu ön plana koymuştuk ve ana kriterimiz Windows gelişimi için hiçbir şeyi değiştirmemekti.
Flyway için bizim için bir çeşit ambalaja ihtiyaç vardıadamlar yazmasın diye SQL sorguları. OOP açısından çalışmaya çok daha yakınlar. Veritabanı nesneleriyle çalışmak için talimatlar yazdık, bir SQL sorgusu oluşturduk ve yürüttük. Veritabanının yeni sürümü hazır, test edildi - her şey yolunda, her şey çalışıyor.
Entity Framework Core'un bir eksisi var - ağır yükler altında optimal olmayan SQL sorguları oluştururve veritabanındaki düşüş önemli olabilir. Ancak yüksek yüklü bir hizmetimiz olmadığı için yükü yüzlerce RPS cinsinden hesaplamıyoruz, bu riskleri kabul ettik ve sorunu geleceğimize devrettik.
Avantajları:
Entity Framework Çekirdeği kutunun dışında çalışır ve geliştirilmesi kolaydırve Uçuş Yolu Mevcut CI'ya kolayca entegre olur. Ancak bunu geliştiriciler için uygun hale getiriyoruz :)
Toplama prosedürü
Puppet, geçişten sorumlu sürüm de dahil olmak üzere paket sürümünde bir değişikliğin geldiğini görüyor. İlk olarak, geçiş komut dosyalarını ve veritabanıyla ilgili işlevleri içeren bir paket yükler. Bunun ardından veritabanı ile çalışan uygulama yeniden başlatılır. Daha sonra kalan bileşenlerin kurulumu geliyor. Paketlerin yüklenme ve uygulamaların başlatılma sırası Puppet manifest dosyasında açıklanmıştır.
Uygulamalar, belirteçler, veritabanı şifreleri gibi hassas verileri kullanır; tüm bunlar, şifrelenmiş biçimde saklandıkları Puppet Master'ın yapılandırmasına çekilir.
TFS sorunları
Her şeyin bizim için gerçekten işe yaradığına karar verdikten ve bunu anladıktan sonra, diğer projelerde Win geliştirme departmanı için TFS'deki montajlarda bir bütün olarak neler olup bittiğine bakmaya karar verdim - hızlı bir şekilde inşa ediyor/sürülüyor olsak da olmasak da ve hız konusunda önemli sorunlar keşfetti.
Ana projelerden birinin montajı 12-15 dakika sürüyor - bu uzun bir süre, böyle yaşayamazsınız. Hızlı bir analiz, G/Ç'de korkunç bir düşüş gösterdi ve bu, dizilerdeydi.
Bileşen bileşen analiz ettikten sonra üç odak noktası belirledim. Birinci - "Kaspersky antivirüs", tüm Windows Build aracılarındaki kaynakları tarar. Saniye - Windows Dizin oluşturucu. Devre dışı bırakılmadı ve dağıtım süreci sırasında her şey Build aracılarında gerçek zamanlı olarak indekslendi.
Üçüncü - Npm'yi yükleyin. Çoğu Boru Hattında tam olarak bu senaryoyu kullandığımız ortaya çıktı. O neden kötü? Npm kurulum prosedürü, bağımlılık ağacı oluşturulduğunda çalıştırılır. paket-lock.jsonProjeyi oluşturmak için kullanılacak paketlerin sürümlerinin kaydedildiği yer. Dezavantajı, Npm kurulumunun her zaman paketlerin en son sürümlerini İnternet'ten almasıdır ve bu, büyük bir proje durumunda çok zaman alır.
Geliştiriciler bazen projenin belirli bir bölümünün veya tamamının nasıl çalıştığını test etmek için yerel bir makine üzerinde denemeler yapar. Bazen yerel olarak her şeyin yolunda olduğu ortaya çıktı, ancak onu topladılar, kullanıma sundular ve hiçbir şey işe yaramadı. Sorunun ne olduğunu anlamaya başlıyoruz - evet, bağımlılıkları olan paketlerin farklı versiyonları.
karar
- AV istisnalarındaki kaynaklar.
- Dizin oluşturmayı devre dışı bırakın.
- Geçiş npm ci.
Npm ci'nin avantajları şunlardır: Bağımlılık ağacını bir kez topluyoruzve geliştiriciye sağlama fırsatını yakalıyoruz güncel paket listesi, yerel olarak istediği kadar deney yapabilir. Bu zaman kazandırır kod yazan geliştiriciler.
Yapılandırma
Şimdi depo yapılandırması hakkında biraz. Tarihsel olarak kullandığımız Nexus dahil olmak üzere depoları yönetmek için Dahili REPO. Bu dahili depo, örneğin kendi kendine yazılan izleme gibi dahili amaçlar için kullandığımız tüm bileşenleri içerir.
Biz de kullanıyoruz Nuget, diğer paket yöneticileriyle karşılaştırıldığında daha iyi önbelleğe alma özelliğine sahip olduğundan.
sonuç
Yapı Aracılarını optimize ettikten sonra ortalama derleme süresi 12 dakikadan 7 dakikaya düştü.
Windows için kullanabileceğimiz ancak bu projede Linux'a geçtiğimiz tüm makineleri sayarsak, yaklaşık 10 $ tasarruf ettik ve bu sadece lisanslarda geçerli ve içeriği de hesaba katarsak daha da fazlası.
Planlar
Gelecek çeyrekte kod dağıtımını optimize etmek için çalışmayı planladık.
Önceden oluşturulmuş bir Docker görüntüsüne geçiş. TFS, örneğin bir Docker görüntüsünün tetik tabanlı montajı da dahil olmak üzere Pipeline'a entegre olmanıza olanak tanıyan birçok eklentiye sahip harika bir şeydir. Bu tetikleyiciyi aynı tetikleyici için yapmak istiyoruz paket-lock.json. Projeyi oluşturmak için kullanılan bileşenlerin bileşimi bir şekilde değişirse yeni bir Docker görüntüsü oluştururuz. Daha sonra konteyneri birleştirilmiş uygulamayla dağıtmak için kullanılır. Şu an durum böyle değil ancak şirketimizde aktif olarak gelişen ve uzun süredir üretim çözümleri sunan Kubernetes'te microservice mimarisine geçmeyi planlıyoruz.
Özet
Herkesi Windows'u atmaya teşvik ediyorum ama bunun nedeni onu nasıl pişireceğimi bilmemem değil. Bunun nedeni çoğu Açık Kaynak çözümünün Linux yığını. iyi misin kaynaklardan tasarruf edin. Bana göre gelecek, güçlü bir topluluğa sahip Linux'taki Açık Kaynak çözümlerine aittir.
Alexander Sinchinov'un konuşmacı profili .
profesyoneller için geliştirme, test etme ve operasyon süreçlerinin profesyoneller tarafından entegrasyonuna yönelik bir konferanstır. İskender'in bahsettiği proje bu yüzden mi? uygulandı ve çalışıyor ve performansın olduğu gün iki başarılı sürüm vardı. Açık 27 ve 28 Mayıs'ta uygulayıcılardan daha da benzer vakalar yaşanacak. Hala son vagona atlayabilirsiniz ve ya da acele etme bilet. Bizimle Skolkovo'da buluşun!
Kaynak: habr.com