Артем Килеев

Для работающего SELinux

chcon -t httpd_sys_rw_content_t /path-to-wp-content -R

И я бы добавил права, и пользователя:

chown -R apache:apache "/path-to-wp-content"
find "/path-to-wp-content" -type f -exec chmod 644 {} \;  
find "/path-to-wp-content" -type d -exec chmod 755 {} \;

Как разделить таблицу, горячие данные оставить на SSD, холодные - на HDD. Для этого во-первых партицирование для разделения таблицы на две. https://habrahabr.ru/post/273933/ (как обычно, внимание на комменты и pg_partman)
Затем, до миграции данных (или сразу при создании партиций), перенос архивных в другой tablespace www.postgresql.org/docs/current/static/sql-createt... stackoverflow.com/a/11228536 на HDD.
Затем миграция данных на партиции.
Вообще-то, это уже может быть вполне достаточно. 1-2млн строк * 365 дней это не запредельно много. Хотя не указан характер данных.

Прозрачный для приложения перенос таблиц на другую железку - FDW, foreign data wrapper. Чем актуальнее postgresql - тем лучше. Пилится штука весьма активно по части оптимального распределения запроса. Дружит ли уже с партицированием - честно, не в курсе.

Прозрачно отправить запрос на две базы и склеить - элементарно view с union all из локальной таблицы и FDW. Только это неинтересный вариант, зачем для запроса на горячие данные дёргать холодную часть базы?

Вдобавок, можете посмотреть в сторону postgresql-xl, greenplum. Первый года полтора назад был не вполне production-ready, сейчас не знаю, второй используется даже в банковской сфере, но как мне помнится катастрофически не годится для OLTP, только OLAP нагрузка.

DevOps расшифровывается как Development Operations.
В повседневные задачи DevOps инженера входит управление инфраструктурой приложений (в основном веб).
Что должен знать и уметь такой инженер - например по клику кнопкой в нужном датацентре произошел деплой приложения. DevOps должен суметь создать этот интерфейс с кнопкой и автоматизировать процесс приобретения инстанса (например в AWS), установки операционной системы и необходимых пакетов, доставки приложения на этот инстанс, прописывания всех настроек в приложении и приведение приложения в полную боевую готовность, т.е. состояние, в котором к приложению можно пускать пользователей.

По пунктам, что нужно знать и уметь:

• неистово учиться и гуглить
  
• сетевые технологии, на уровне маршрутизации, TCP/IP, DNS, SMTP и остальных протоколов начиная с 3 уровня модели OSI
  
• сетевые операционные системы (преимущественно семейства Linux) на уровне автоматизирования установки, обновления, настройки безопасности и мониторинга
  
• системы виртуализации (Xen, OpenVZ) и контейнеризации (Docker, Vagrant)
  
• настраивать сервера и мигрировать конфигурации, например перейти с Apache на Nginx, или с PHP на HHVM
  
• Chef
  
• Puppet
  
• Ansible
  
• Capistrano
  
• VCS
  
• AWS/OpWorks/CloudFormation/CodeDeploy, OpenStack
  
• Munin/Logstash/Kibana и другие связки для мониторинга
  
• Continuous delivery
  
• Программировать на Bash, Ruby, Python, Go, Perl, уметь понимать конфиги на самых экзотических языках, например YAML
  
• TDD
  
• продукты hashicorp
  
• автоматизировать создание и восстановление бэкапов баз данных
  
• масштабировать приложения по горизонтали (настраивать балансировщики, реверс-проксирование, шардинг и репликацию в базах)
  
• рассчитывать и оптимизировать издержки на поддержание инфраструктуры приложений
  
• видеть будущее инфраструктуры приложения и компании, двигать инфраструктуру в это будущее
  

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

По умолчанию наследоваться не будет. Однако, если аннотация помечена как Inherited, то наследуется. Так как чаще всего аннотации не наследуются, то можно использоваться вспомагательные средства для поиска аннотаций у класса и его родителей, например библиотека Spring Core содержит методы findAnnotations для поиска конкретных аннотаций у класса (или его родителей) или метода (или методов родителя которые переопределенны данным методом).

Вот хороший пример, объясняющий принцип работы Inherited: тырц.

Спецификация - это сухое описание продукта или подхода. ТТХ если хотите. Документация же может содержать советы по применению продукта основанного на спецификации, или наоборот совету по не применению.

По ссылке, которую Вы привели находится спецификация API 8 JDK.

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

Спецификация языка Java есть по такому адресу: https://docs.oracle.com/javase/specs/.

ИМХО, понять ее не в состоянии даже те, кто ее написал)

www.postgresql.org/docs/9.5/static/functions-admin.html

pg_read_file Return the contents of a text file.

Короче говоря, зачем вы пытаетесь бинарник читать текстовой функцией, а не берёте штатный pg_read_binary_file, который как раз bytea и читает.

echo "nameserver 8.8.8.8" > /etc/resolv.conf

Привет, использую альфу
1 только skrill
2 карты альфабанка
3 альфа счета

Так сложилось, собираюсь попробовать тинькофф банк, руководствуясь не хранить все сбережения в одной корзине.

Личный опыт:
-У альфа банкоматов не бывает очередей
-Выдает баксы без комиссии со своего счета, при условии что снимаешь с долларовой карты
-Более-менее удобный интерфейс
-Не особо интересуются в отличии от сбербанка откуда у меня появляются деньги на счетах
-Дружелюбный персонал
-В налоговую не стучат, только если налоговая спросит лично про вас (узнавал у знакомых сотрудников, инфа свежая, месячной давности)
-Много филиалов по миру, где можно восстановить карту и обратится за другими услугами
-Автоматом и мгновенно блокируют карту, если произошла сомнительная операция, снять лок можно просто позвонив, если все таки операция была не ваша, перевыпускают карту без вопросов и комиссий

Отвечал по skrill в этой теме: Вывод средств из oDesk. Как получить $ в России?

Статья, которую должен прочитать каждый.

DevOps - не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

Человека, который внедряет DevOps, обычно называют... как хотят. Чаще всего этим занимается какой-нибудь нон-конформист в команде.

Профессии, которые отрисуются в процессе построения этой методологии следующие:

• Build Engineer - инженер, который управляет зависимостями, сборками, конфликтами кода.
• Release Engineer - инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
• Automation Engineer - инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker - его инструментарий.
• Site Reliability Engineer - инженер, который поддерживает ops (апгрейды, расширение железа)
• Configuration Manager - непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President
  

В список не вошла самая главная специальность - "психолог". Человек, который должен следить за людьми и вычислять психологически важные аспекты команды, пораждающие боттлнеки производительности.

Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
Назовем эту компанию BRAE/CM для краткости.
Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
То есть сисадмины начинают рулить еще до того, как код попадет к ним - на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам - на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле "ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось - пусть сами и чинят".

Так вот эта работа - завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

Еще один момент. В домашних условиях можно выучить инструменты на базовом уровне. Но не поварившись в одной кастрюле с реальными разработчиками, смысл всей этой кухни не понять. Так что сразу забейте. Но если хотите, могу описать пошаговый длинный путь как стать RE/CM:

Сразу оговорюсь по языкам.
У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как "технинческий долг" и "управление процессом разработки". И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
Другими словами, если в среде разработчиков выбор языка - тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java - это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

Каждый последующий пункт, кроме особо длинного первого, будет выливаться в неделю-две достаточно плотного труда. Если не прокрастенировать и уделять этому по несколько часов вечером.

Итак, что делать:
1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
3) Поставить VirtualBox (не VMWare!!!)
4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven'у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем - не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins'ом задеплойте.
11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

Усложняем систему.
12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
14) Прикручиваем мониторинг Sensu.
15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

А теперь немного уходим в управление проектом:
21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
22) Поставить Atlassian Stash и связать его с Jira.
23) Переехать со своего SVN на GIT, предоставленный Stash'ем.
24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток - по аналогии с принципом программирования "reuse code". У Вас будет reuse job :)
28) Сделать pull request, самому сделать code review и самому себя же за-approve'ить. После этого сделать merge своей ветки в master.
29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
a) разбиваете control-файл на несколько пакетов, возможно с lib*,
b) оверрайдите все ~20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
c) раскидываете файлы по .install
d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make - то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием "регрессионные тесты".

Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.

GWT - один из лучших вариантов для такой задачи. Если у вас постоянные пользователи, то сгенерированный GWT-скрипт будет грузиться в браузер единожды, и в дальнейшем весь интерфейс будет рисоваться в браузере, без обращений к серверу. Обращения к серверу понадобятся только для получения/передачи чистых данных, без html/xml оберток, и делаться это будет только тогда, когда это действительно требуется вашей логике, т.е., далеко не каждое действие пользователя будет вызывать обращение к серверу. К тому же, можно кешировать часто используемые данные на клиенте, снижая трафик и нагрузку на сервер. Еще один плюс - очень много логики (например, сложный форматно-логический контроль) можно выполнять на клиенте, без обращений к серверу.

Насчет дизайна: в GWT есть минимальный набор компонентов, с помощью которого можно "нарисовать" динамический интерфейс любой сложности. Если ваша цель - не завлечь на сайт пользователей красивыми/необычными рюшечками, а создать функциональное рабочее место, то базовых компонентов должно хватить.

Кстати, тот же Vaadin работает на GWT. Он дополняет его своими компонентами, но убивает на корню один из главных плюсов GWT - высокую степень независимости от сервера во время действий пользователя.

Насчет нагрузки: 1000 человек, постоянно работающих в приложении, это много. Готовьте мощные сервера под СУБД и под сервер приложений, плюс держите в уме возможность развертывания кластера для распределения нагрузки.

Если Вы - Java-программист, то разрабатывать под GWT будет приятно, а точнее - как обычно. Например, процесс разработки под JSF - то ещё "удовольствие", GWT в этом плане гораздо лучше.