werf 1.1 шығарылымы: бүгінгі құрылысшыны жақсарту және болашаққа арналған жоспарлар

верф бұл Kubernetes қолданбаларын құруға және жеткізуге арналған ашық бастапқы GitOps CLI утилитасы. Уәде етілгендей, v1.0 нұсқасының шығарылымы werf-қа жаңа мүмкіндіктерді қосудың және дәстүрлі тәсілдерді қайта қараудың бастамасы болды. Енді біз дамудағы үлкен қадам және болашаққа негіз болатын v1.1 шығарылымын ұсынуға қуаныштымыз коллектор верф. Нұсқа қазір қол жетімді арна 1.1 дана.

Шығарылымның негізі - жаңа кезеңді сақтау архитектурасы және екі коллектордың жұмысын оңтайландыру (Stapel және Dockerfile үшін). Жадтың жаңа архитектурасы бірнеше хосттардан бөлінген жинақтарды және бір хостта параллель құрастыруларды іске асыру мүмкіндігін ашады.

Жұмысты оңтайландыру кезеңдік қолтаңбаларды есептеу сатысында қажетсіз есептеулерден арылуды және файлдардың бақылау сомасын есептеу механизмдерін тиімдірекке өзгертуді қамтиды. Бұл оңтайландыру werf көмегімен жобаны құрудың орташа уақытын қысқартады. Барлық кезеңдер кэште болған кезде бос құрастырулар кезеңдері-сақтау, қазір өте жылдам. Көп жағдайда құрастыруды қайта бастау 1 секундтан аз уақытты алады! Бұл сондай-ақ топтардың жұмыс процесінің кезеңдерін тексеру процедураларына да қатысты. werf deploy и werf run.

Сондай-ақ осы шығарылымда мазмұн бойынша суреттерді тегтеу стратегиясы пайда болды - мазмұнға негізделген тегтеу, ол қазір әдепкі бойынша қосылған және жалғыз ұсынылған.

werf v1.1-дегі негізгі инновацияларды егжей-тегжейлі қарастырайық және сонымен бірге болашаққа арналған жоспарлар туралы айтып берейік.

werf v1.1 нұсқасында не өзгерді?

Жаңа кезеңді атау пішімі және кэштен кезеңдерді таңдау алгоритмі

Жаңа сахналық атауды құру ережесі. Енді әрбір кезең құрастыруы 2 бөліктен тұратын бірегей сахна атауын жасайды: қолтаңба (v1.0 нұсқасындағыдай) және бірегей уақытша идентификатор.

Мысалы, сахналық кескіннің толық атауы келесідей болуы мүмкін:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...немесе жалпы:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Мұнда:

• SIGNATURE сахналық қолтаңба болып табылады, ол сахналық мазмұнның идентификаторын білдіреді және осы мазмұнға әкелген Git-тегі өңдеулер тарихына байланысты;
• TIMESTAMP_MILLISEC жаңа кескінді құрастыру кезінде жасалатын кепілдік берілген бірегей кескін идентификаторы болып табылады.

Кэштен кезеңдерді таңдау алгоритмі Git тапсырмаларының қатынасын тексеруге негізделген:

1. Werf белгілі бір кезеңнің қолтаңбасын есептейді.
2. В кезеңдері-сақтау Берілген қол қою үшін бірнеше кезең болуы мүмкін. Werf қолтаңбаға сәйкес келетін барлық кезеңдерді таңдайды.
3. Ағымдағы кезең Git-ке байланысты болса (git-архив, Git патчтары бар теңшелетін кезең: install, beforeSetup, setup; немесе git-latest-patch), содан кейін werf ағымдағы міндеттеменің атасы болып табылатын міндеттемемен байланысты кезеңдерді ғана таңдайды (ол үшін құрастыру шақырылады).
4. Қалған қолайлы кезеңдерден біреуі таңдалады - жасалған күні бойынша ең ескісі.

Әртүрлі Git тармақтарына арналған кезеңде бірдей қолтаңба болуы мүмкін. Бірақ werf қолтаңбалар сәйкес болса да, әртүрлі тармақтармен байланысты кэшті осы тармақтар арасында пайдаланудан сақтайды.

→ Құжаттама.

Сахна қоймасында кезеңдерді құру және сақтаудың жаңа алгоритмі

Егер кэштен кезеңдерді таңдау кезінде werf сәйкес кезеңді таппаса, онда жаңа кезеңді құрастыру процесі басталады.

Бірнеше процестер (бір немесе бірнеше хосттарда) бір кезеңді шамамен бір уақытта құра бастауы мүмкін екенін ескеріңіз. Werf оптимистік блоктау алгоритмін пайдаланады кезеңдері-сақтау жаңадан жиналған суретті сақтау сәтінде кезеңдері-сақтау. Осылайша, жаңа кезең құрастыру дайын болғанда, верф блоктары кезеңдері-сақтау және ол жерде сәйкес сурет бұдан былай жоқ болса ғана жаңадан жиналған кескінді сақтайды (қолтаңба және басқа параметрлер бойынша - кэштен кезеңдерді таңдаудың жаңа алгоритмін қараңыз).

Жаңадан жиналған кескіннің бірегей идентификаторы болатынына кепілдік беріледі TIMESTAMP_MILLISEC (сахна атауының жаңа форматын қараңыз). Жағдайда кезеңдері-сақтау сәйкес сурет табылса, werf жаңадан құрастырылған кескінді тастайды және кескінді кэштен пайдаланады.

Басқаша айтқанда: кескінді құруды аяқтаудың бірінші процесі (ең жылдам) оны кезең-сақтауда сақтау құқығын алады (содан кейін барлық құрастырулар үшін дәл осы жалғыз сурет қолданылады). Баяу құрастыру процесі жылдамырақ процесті ағымдағы кезеңнің құрастыру нәтижелерін сақтауға және келесі құрастыруға көшуге ешқашан бөгет жасамайды.

→ Құжаттама.

Dockerfile құрастырушысының өнімділігі жақсарды

Қазіргі уақытта Докер файлынан құрастырылған кескін үшін кезеңдердің құбыры бір кезеңнен тұрады - dockerfile. Қолтаңбаны есептеу кезінде файлдардың бақылау сомасы есептеледі context, ол құрастыру кезінде пайдаланылады. Осы жақсартуға дейін werf рекурсивті түрде барлық файлдарды аралап шықты және әрбір файлдың мәтінмәні мен режимін қосу арқылы бақылау сомасын алды. v1.1 нұсқасынан бастап werf Git репозиторийінде сақталған есептелген бақылау сомасын пайдалана алады.

Алгоритм негізделген git ls-ағаш. Алгоритм жазбаларды ескереді .dockerignore және қажет болғанда ғана файл тармағын рекурсивті аралайды. Осылайша, біз файлдық жүйені оқудан және алгоритмнің өлшемге тәуелділігін ажыраттық. context маңызды емес.

Алгоритм сонымен қатар бақыланбаған файлдарды тексереді және қажет болған жағдайда оларды бақылау сомасында есепке алады.

Файлдарды импорттау кезінде жақсартылған өнімділік

werf v1.1 нұсқалары rsync серверін пайдаланады артефактілер мен кескіндерден файлдарды импорттау. Бұрын импорттау хост жүйесінен каталогты орнату арқылы екі қадаммен орындалды.

MacOS жүйесіндегі импорт өнімділігі бұдан былай Docker көлемдерімен шектелмейді және импорттау Linux және Windows сияқты уақыт көлемінде аяқталады.

Мазмұнға негізделген тегтеу

Werf v1.1 сурет мазмұны бойынша тегтеуді қолдайды - мазмұнға негізделген тегтеу. Алынған Docker кескіндерінің тегтері сол кескіндердің мазмұнына байланысты.

Пәрменді орындау кезінде werf publish --tags-by-stages-signature немесе werf ci-env --tagging-strategy=stages-signature деп аталатын суреттерді жариялады сахналық қолтаңба сурет. Әрбір сурет осы кескіннің кезеңдерінің өзіндік қолтаңбасымен белгіленеді, ол әр кезеңнің жеке қолтаңбасы сияқты бірдей ережелерге сәйкес есептеледі, бірақ кескіннің жалпы идентификаторы болып табылады.

Кескін кезеңдерінің қолтаңбасы мыналарға байланысты:

1. осы суреттің мазмұны;
2. осы мазмұнға әкелген Git өзгерістерінің тарихы.

Git репозиторийінде әрқашан кескін файлдарының мазмұнын өзгертпейтін жалған міндеттемелер болады. Мысалы, тек түсініктемелермен немесе біріктіру тапсырмаларымен немесе Git ішіндегі кескінге импортталмайтын файлдарды өзгертетін міндеттемелер.

Мазмұнға негізделген тегтеуді пайдаланған кезде, кескіннің мазмұны өзгермеген болса да, кескін атауының өзгеруіне байланысты Kubernetes бағдарламасындағы қолданба бөлімдерін қажетсіз қайта іске қосу мәселелері шешіледі. Айтпақшы, бұл бір Git репозиторийінде бір қолданбаның көптеген микросервистерін сақтауға кедергі болатын себептердің бірі.

Сондай-ақ, мазмұнға негізделген тегтеу Git тармақтарында тегтеуден гөрі сенімдірек тегтеу әдісі болып табылады, себебі алынған кескіндердің мазмұны бір тармақтың бірнеше тапсырмаларын жинақтау үшін CI жүйесінде конвейерлердің орындалу ретіне байланысты емес.

маңызды: қазірден бастап кезеңдері-қол қою Мүмкін жалғыз ұсынылатын тегтеу стратегиясы. Ол әдепкі бойынша пәрменде пайдаланылады werf ci-env (басқа белгілеу схемасын нақты көрсетпесеңіз).

→ Құжаттама. Бұл мүмкіндікке жеке басылым да арналады. ЖАҢАРТЫЛДЫ (3 сәуір): егжей-тегжейлі мақала жарияланған.

Тіркеу деңгейлері

Пайдаланушы енді шығысты басқаруға, тіркеу деңгейін орнатуға және жөндеу ақпаратымен жұмыс істеуге мүмкіндігі бар. Опциялар қосылды --log-quiet, --log-verbose, --log-debug.

Әдепкі бойынша шығыс ең аз ақпаратты қамтиды:

Толық шығысты пайдаланған кезде (--log-verbose) werf қалай жұмыс істейтінін көре аласыз:

Егжей-тегжейлі шығыс (--log-debug), werf жөндеу ақпаратына қоса, пайдаланылған кітапханалардың журналдарын да қамтиды. Мысалы, сіз Docker тізілімімен өзара әрекеттесу жолын көре аласыз, сондай-ақ көп уақыт жұмсалатын орындарды жаза аласыз:

Кейінгі жоспарлар

Ескерту! Төменде сипатталған опциялар белгіленген v1.1 осы нұсқада қол жетімді болады, олардың көпшілігі жақын болашақта. Жаңартулар автоматты жаңартулар арқылы келеді multiwerf пайдалану кезінде. Бұл мүмкіндіктер v1.1 функцияларының тұрақты бөлігіне әсер етпейді, олардың көрінісі бар конфигурацияларға пайдаланушының қолмен араласуын қажет етпейді.

Әртүрлі Docker Registry іске асыруларына толық қолдау көрсету (ЖАҢА)

• Нұсқа: v1.1
• Күні: наурыз
• Іс

Мақсат - пайдаланушы werf пайдалану кезінде шектеусіз теңшелетін енгізуді пайдалану.

Қазіргі уақытта біз толық қолдауға кепілдік беретін келесі шешімдер жинағын анықтадық:

• Әдепкі (кітапхана/тізілім)*,
• AWS ECR
• Лазур*,
• Docker хабы
• GCR*,
• GitHub бумалары
• GitLab тізілімі*,
• айлақ*,
• Quay.

Қазіргі уақытта werf арқылы толық қолдау көрсетілетін шешімдер жұлдызшамен белгіленген. Басқалар үшін қолдау бар, бірақ шектеулер бар.

Екі негізгі проблеманы анықтауға болады:

• Кейбір шешімдер Docker Registry API арқылы тегтерді жоюға қолдау көрсетпейді, бұл пайдаланушылардың werf автоматты тазалауын пайдалануына жол бермейді. Бұл AWS ECR, Docker Hub және GitHub пакеттеріне қатысты.
• Кейбір шешімдер кірістірілген репозиторийлерге (Docker Hub, GitHub пакеттері және Quay) қолдау көрсетпейді немесе қолдамайды, бірақ пайдаланушы оларды UI немесе API (AWS ECR) арқылы қолмен жасауы керек.

Біз осы және басқа мәселелерді шешімдердің жергілікті API интерфейстерін пайдалана отырып шешеміз. Бұл тапсырма сонымен қатар олардың әрқайсысына арналған сынақтармен верф жұмысының толық циклін қамтуды қамтиды.

Бөлінген кескін құрастыру (↑)

• Нұсқа: v1.2 v1.1 (бұл мүмкіндікті іске асырудың басымдығы арттырылды)
• Мерзімі: наурыз-сәуір наурыз
• Іс

Қазіргі уақытта werf v1.0 және v1.1 кескіндерді құру және жариялау және қолданбаны Kubernetes жүйесіне орналастыру операциялары үшін тек бір арнайы хостта пайдаланылуы мүмкін.

Kubernetes-те қолданбаларды құру және орналастыру бірнеше ерікті хосттарда іске қосылғанда және бұл хосттар құрастырулар (уақытша жүгірушілер) арасында өз күйін сақтамаған кезде werf-тің бөлінген жұмысының мүмкіндіктерін ашу үшін werf пайдалану мүмкіндігін іске асыру үшін қажет. Docker тізілімін кезеңдік дүкен ретінде.

Бұрын werf жобасы әлі күнге дейін dapp деп аталатын кезде, оның мұндай мүмкіндігі болды. Дегенмен, біз werf-те бұл функцияны енгізу кезінде ескеру қажет бірқатар мәселелерге тап болдық.

ескерту. Бұл мүмкіндік коллектордың Kubernetes подкасттарының ішінде жұмыс істеуін талап етпейді, себебі Бұл әрекетті орындау үшін жергілікті Docker серверіне тәуелділіктен құтылу керек (Kubernetes бөлімінде жергілікті Docker серверіне кіру мүмкін емес, себебі процестің өзі контейнерде жұмыс істейді, ал werf қолдамайды және қолдамайды. желі арқылы Docker серверімен жұмыс істеу). Kubernetes іске қосу үшін қолдау бөлек жүзеге асырылады.

GitHub әрекеттеріне ресми қолдау көрсету (ЖАҢА)

• Нұсқа: v1.1
• Күні: наурыз
• Іс

werf құжаттамасын қамтиды (бөлімдер анықтамалық и гид), сондай-ақ werf-пен жұмыс істеуге арналған ресми GitHub әрекеті.

Сонымен қатар, ол werf-ке эфемерлі жүгірушілермен жұмыс істеуге мүмкіндік береді.

Пайдаланушының CI жүйесімен өзара әрекеттесу механизмі қолданбаны құру/шығару үшін белгілі әрекеттерді бастау үшін тарту сұрауларына белгілер қоюға негізделеді.

werf (↓) бар қолданбаларды жергілікті әзірлеу және орналастыру

• Нұсқа: v1.1
• Мерзімі: қаңтар-ақпан сәуір
• Іс

Негізгі мақсат - қолданбаларды жергілікті және өндірісте, күрделі әрекеттерсіз, қораптан тыс орналастыру үшін бірыңғай бірыңғай конфигурацияға қол жеткізу.

werf қолданбасының кодын өңдеуге және жөндеу үшін іске қосылған қолданбадан бірден кері байланыс алуға ыңғайлы болатын жұмыс режимі болуы керек.

Жаңа тазалау алгоритмі (ЖАҢА)

• Нұсқа: v1.1
• Күндері: сәуір
• Іс

Процедурадағы werf v1.1 ағымдағы нұсқасында cleanup Мазмұнға негізделген тегтеу схемасы үшін кескіндерді тазалауға арналған ереже жоқ - бұл кескіндер жинақталады.

Сондай-ақ, werf (v1.0 және v1.1) ағымдағы нұсқасы тегтеу схемалары бойынша жарияланған кескіндер үшін әртүрлі тазалау саясаттарын пайдаланады: Git тармағы, Git тегі немесе Git commit.

Барлық тегтеу схемалары үшін біріктірілген Git-те орындалу тарихына негізделген кескіндерді тазалаудың жаңа алгоритмі ойлап табылды:

• Әрбір git HEAD (тармақтар мен тегтер) үшін N1 ең соңғы орындалатын әрекеттермен байланысты N2 кескіннен артық емес сақтаңыз.
• Әрбір git HEAD (тармақтар мен тегтер) үшін N1 ең соңғы орындалатын әрекеттермен байланысты N2-ден көп емес кезеңдік кескіндерді сақтаңыз.
• Кез келген Kubernetes кластерінің ресурстарында пайдаланылатын барлық кескіндерді сақтаңыз (конфигурация файлының және аттар кеңістігінің барлық kube мәтінмәндері сканерленеді; бұл әрекетті арнайы опциялармен шектей аласыз).
• Helm шығарылымдарында сақталған ресурс конфигурациясының манифестерінде пайдаланылатын барлық кескіндерді сақтаңыз.
• Кескінді жоюға болады, егер ол git жүйесінен ешбір HEAD-мен байланысты болмаса (мысалы, сәйкес HEAD өзі жойылғандықтан) және Kubernetes кластеріндегі және Helm шығарылымдарындағы ешбір манифесттерде пайдаланылмаса.

Параллель кескін құру (↓)

• Нұсқа: v1.1
• Күні: қаңтар-ақпан сәуір*

werf ағымдағы нұсқасы ішінде сипатталған суреттер мен артефактілерді жинайды werf.yaml, ретімен. Суреттер мен артефактілердің тәуелсіз кезеңдерін құрастыру процесін параллельдеу, сондай-ақ ыңғайлы және ақпараттандыруды қамтамасыз ету қажет.

* Ескертпе: горизонтальды масштабтау мүмкіндіктерін қосатын, сондай-ақ GitHub әрекеттерімен werf пайдалануды қосатын бөлінген жинақты іске асырудың басымдылығына байланысты соңғы мерзім ауыстырылды. Параллельді құрастыру - бір жобаны құрастыру кезінде тік масштабтауды қамтамасыз ететін келесі оңтайландыру қадамы.

3-ші рульге көшу (↓)

• Нұсқа: v1.2
• Мерзімі: ақпан-наурыз мамыр*

Жаңа код базасына тасымалдауды қамтиды Руль 3 және бар қондырғыларды көшірудің дәлелденген, ыңғайлы тәсілі.

* Ескертпе: Helm 3-ке ауысу werf-ке маңызды мүмкіндіктерді қоспайды, өйткені Helm 3-тің барлық негізгі мүмкіндіктері (3 жақты біріктіру және өңдеуші жоқ) werf-те әлдеқашан енгізілген. Оның үстіне, werf бар қосымша мүмкіндіктер көрсетілгендерге қосымша. Дегенмен, бұл көшу біздің жоспарымызда қалды және жүзеге асырылады.

Kubernetes конфигурациясын сипаттауға арналған Jsonnet (↓)

• Нұсқа: v1.2
• Мерзімі: қаңтар-ақпан сәуір-мамыр

Werf Jsonnet пішіміндегі Kubernetes конфигурациясының сипаттамаларын қолдайды. Сонымен бірге werf Helm-пен үйлесімді болып қалады және сипаттама пішімін таңдау мүмкіндігі болады.

Себебі, Go үлгілері, көптеген адамдардың пікірінше, жоғары кіру кедергісіне ие және бұл үлгілердің кодының түсініктілігі де зардап шегеді.

Kubernetes конфигурациясын сипаттаудың басқа жүйелерін (мысалы, Kustomize) енгізу мүмкіндігі де қарастырылуда.

Kubernetes ішінде жұмыс істеу (↓)

• Нұсқа: v1.2
• Мерзімі: сәуір-мамыр-мамыр-маусым

Мақсат: Кескіндердің құрастырылғанын және қолданбаның Kubernetes жүйесіндегі жүгіргіштер арқылы жеткізілуін қамтамасыз ету. Анау. Жаңа кескіндерді тікелей Kubernetes қосқыштарынан жасауға, жариялауға, тазалауға және орналастыруға болады.

Бұл мүмкіндікті іске асыру үшін алдымен таратылған кескіндерді құра білу керек (жоғарыдағы тармақты қараңыз).

Ол сондай-ақ Docker серверінсіз (мысалы, Канико тәрізді құрастыру немесе пайдаланушы кеңістігінде құрастыру) құрастырушының жұмыс режиміне қолдау көрсетуді қажет етеді.

Werf Kubernetes-те тек Dockerfile-мен ғана емес, сонымен қатар қадамдық қайта құрулары және Ansible бар Stapel құрастырушысымен де қолдау көрсетеді.

Ашық дамуға қадам

Біз қауымдастықты жақсы көреміз (GitHub, Telegram) және біз көбірек адамдар werf-ті жақсартуға көмектесіп, біз қозғалатын бағытты түсініп, дамуға атсалысқымыз келеді.

Жақында ауысу туралы шешім қабылданды GitHub жобалық тақталары біздің ұжымның жұмыс процесін ашу мақсатында. Енді сіз алдағы жоспарларды, сондай-ақ келесі бағыттар бойынша ағымдағы жұмыстарды көре аласыз:

• Құжаттар және сайт;
• тестілеу;
• Қателер және нашар UX;
• 1.1.

мәселелер бойынша көп жұмыс атқарылды:

• Маңыздысы жойылды.
• Қолданыстағылары детальдар мен бөлшектердің жеткілікті санымен бір форматқа келтіріледі.
• Идеялар мен ұсыныстар бар жаңа мәселелер қосылды.

v1.1 нұсқасын қалай қосуға болады

Нұсқа қазір қол жетімді арна 1.1 дана (арналарда тұрақты и тастай берік дегенмен, тұрақтандыру орын алған кезде шығарылымдар пайда болады ea өзі пайдалану үшін жеткілікті тұрақты, өйткені арналардан өтті альфа и бета). Іске қосылды multiwerf арқылы келесі жолмен:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

қорытынды

Stapel және Dockerfile құрастырушыларына арналған жаңа кезеңдік сақтау архитектурасы және құрастырушыны оңтайландыру werf-те бөлінген және параллель құрастыруларды енгізу мүмкіндігін ашады. Бұл мүмкіндіктер жақында бірдей v1.1 шығарылымында пайда болады және автоматты жаңарту механизмі арқылы автоматты түрде қолжетімді болады (пайдаланушылар үшін multiwerf).

Бұл шығарылымда кескін мазмұнына негізделген тегтеу стратегиясы қосылды - мазмұнға негізделген тегтеу, ол әдепкі стратегияға айналды. Негізгі пәрмен журналы да қайта өңделген: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Келесі маңызды қадам - ​​таратылған жинақтарды қосу. v1.0 нұсқасынан бастап үлестірілген құрастырулар параллель құрастыруларға қарағанда жоғары басымдыққа айналды, себебі олар werf-ке көбірек мән береді: құрылысшылардың тік масштабтауы және әртүрлі CI/CD жүйелеріндегі эфемерлі құрастырушыларға қолдау көрсету, сондай-ақ GitHub әрекеттеріне ресми қолдау көрсету мүмкіндігі. . Сондықтан параллельді жинақтарды орындау мерзімдері ауыстырылды. Дегенмен, біз екі мүмкіндікті де мүмкіндігінше тезірек жүзеге асыруға тырысамыз.

Жаңалықты бақылаңыз! Бізге келуді ұмытпаңыз GitHubмәселені жасау, барын табу және плюс қосу, PR жасау немесе жай ғана жобаның дамуын қарау.

PS

Біздің блогта да оқыңыз:

• «werf 1.0 тұрақты нұсқасын таныстыру: GitOps-тың оған қандай қатысы бар, мәртебесі және жоспарлары»
• «werf - біздің Kubernetes-тегі CI/CD құралы (шолу және бейне есеп)«;
• werf-тегі инновациялар туралы ескертулер сериясы:
  • «werf-ке 3 жақты біріктіру: Helm көмегімен Кубернетеске «стероидтарда» орналастыру«;
  • «Күрделі Helm диаграммаларын шығару үшін werf пайдалану«;
  • «Верфте монорепо және мультирепо қолдауы және оған Docker тізілімінің қандай қатысы бар«;
  • «Енді сіз әдеттегі Docker файлын пайдаланып werf ішінде Docker кескіндерін құра аласыз«.

Ақпарат көзі: www.habr.com