Dark mode остается главной тенденцией в дизайне сайтов и приложений. Мы нашли классную статью на эту тему и решили поделиться переводом. Мнение пользователей, реализация и поддержка dark mode, рекомендации для разработчиков далее в статье. А на какой стороне вы?

Просто хайп или необходимость? Узнайте больше о темном режиме. Я расскажу, как добавить поддержку dark mode на благо ваших пользователей!

Введение

По данной теме я провел объемное исследование, изучил историю вопроса. Если вас интересует только работа с темным режимом, смело пропускайте первый раздел.

Как мы мигрировали 700+ серверов на Salt

Долгое время нас устраивала сложная и неповоротливая конфигурация с 2 Git-репозиториями, где часть данных хранится в MySQL, а другая часть Puppet 3.8. Но наши потребности постепенно росли, количество сервисов увеличивалось, а производительность конфигурации снижалась. Тогда мы поставили перед собой задачу усовершенствовать конфигурацию, оптимизировав все имеющиеся данные и инструменты.

Наша команда подобрала для себя подходящую конфигурацию в 3 этапа. Делимся опытом оптимизации Salt, как применить и настроить без лишних усилий.

Перед горизонтальным и вертикальным масштабированием инфраструктуры первым делом необходимо убедиться, что ресурсы используются правильно, а конфигурация приложения не создает узких мест для его производительности. Главная цель команды инженеров — обеспечить постоянную, бесперебойную работу любой спроектированной и развернутой системы с помощью минимальных ресурсов.

Мы столкнулись с указанной выше проблемой, когда наша развернутая система ежедневно использовалась миллионом пользователей, которые подключались всплесками время от времени. Это значит, что развертывание нескольких серверов или их масштабирование не будет в данной ситуации оптимальным решением.

Рассказываем об опыте Timeweb

Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.

Bug Bounty программа как свежая сила в деле багхантинга

Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.

Компания может запустить подобную программу самостоятельно, своими силами организовав все процессы и взаимодействия. Второй вариант — обратиться к специальным Bug Bounty платформам: заключаем соглашение, и армия багхантеров приступает к работе.

Timeweb запустила Bug Bounty программу около года назад. На тот момент в компании не было специалистов с опытом в этой области, всё приходилось делать методом проб и ошибок. В сети почти никто не делится рекомендациями по построению данного процесса, поэтому часто изобретаются велосипеды, а знания обычно передаются в разговорах с коллегами у кофе-машины.

В этой статье мы расскажем, как организовать запуск Bug Bounty программы, если вы ни разу этим не занимались, на что стоит обратить внимание и как еще можно проверить состояние системы информационной безопасности.

На прошлой неделе в первой части этой статьи мы описали, как построена связка Apache и Nginx в Timeweb. Мы очень благодарны читателям за вопросы и активное обсуждение! Сегодня рассказываем, как реализована доступность нескольких версий PHP на одном сервере и почему мы гарантируем безопасность данных нашим клиентам.


Виртуальный хостинг (Shared-хостинг) предполагает, что на одном сервере размещено множество аккаунтов клиентов. На аккаунте одного клиента, как правило, находится несколько сайтов. Сайты работают как на готовых CMS (например, Bitrix), так и на кастомных. Таким образом, технические требования у всех систем разные, поэтому в рамках одного сервера необходимо управлять несколькими версиями PHP.

Как реализована связка Apache & Nginx в Timeweb

Для многих компаний Nginx + Apache + PHP — очень типовая и распространенная связка, и Timeweb здесь не стал исключением. Однако разобраться, как именно она реализована, может быть любопытно и полезно.



Использование такой связки, конечно, продиктовано потребностями наших клиентов. И Nginx и Apache играют особую роль, каждый решает определенную задачу.

Основные настройки Apache выполняются в конфигурационных файлах самого Apache, а настройки для клиентских сайтов происходят через файл .htaccess. .htaccess — конфигурационный файл, в котором клиент может самостоятельно настроить правила и поведение веб-сервера. Такая настройка будет относиться конкретно к его сайту. Например, благодаря функционалу Apache пользователи могут менять режим работы в рамках одной версии PHP с mod_php на mod_cgi; можно настраивать редиректы, оптимизацию для SEO, удобный URL, некоторые лимиты для PHP.

Nginx используется как прокси-сервер для перенаправления трафика на Apache и как веб-сервер для отдачи статического контента. Также для Nginx мы разработали модули безопасности, которые позволяют защитить данные наших пользователей, например, разделить права доступа.

Представим, что какой-то пользователь заходит на сайт нашего клиента. Сначала пользователь попадает на Nginx, который отдает статический контент. Это происходит мгновенно. Затем, когда дело доходит до загрузки PHP, Nginx перенаправляет запрос на Apache. И Apache совместно с PHP уже генерирует динамический контент.

Особенности связки Apache & Nginx в Timeweb

На нашем виртуальном хостинге реализованы 2 основные схемы работы Apache & Nginx: Shared и Dedicated.